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Preface 
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ABSTRACT 


^The  air  commander's  ability  to  shape  and  control  the  battle  is 
just  as  critical  for  victory  in  the  air  as  it  is  on  the  ground.  The 
inability  of  the  commander  to  control  his  forces  in  a  timely  manner 
will  see  them  defeated  by  a  more  flexible  opponent.  Decision 
support  systems  (DSS)  are  a  tool  which  can  aid  the  commander  by 
giving  the  overwhelming  masses  of  information  a  structure  for  the 
decision  process  at  hand  and  by  aiding  the  evaluation  of  this 
information. 

The  problem  of  being  inundated  by  data  also  applies  to 
electronic  combat  (EC)  assets.  The  commander's  control  of  a  these 
scarce  resources  requires  a  complex  assessment  of  an  enemy's  air 
defense  system  and  the  determination  of  how  to  employ  EC  assets  to 
gain  the  best  degradation/destruction  of  those  defenses. 

To  develope  a  DSS  to  aid  the  commander,  the  functions  and 
requirements  of  the  system  must  be  established.  The  purpose  of  this 
thesis  was  to  investigate  the  use  of  the  storyboarding  process  as  a 
vehicle  for  the  establishment  of  systems  requirements.  The  DSS 
focused  on  for  this  study  was  an  aid  to  the  Electronic  Combat 
Coordination  Officer  (ECCO)  for  the  dynamic  retasking  of  airborne  EC 
assets.  The  adaptive  design  process  was  used,  therefore  only  a  small 
core  was  initially  proposed.  The  remainder  of  the  system  would 

follow  as  further  requirements  were  generated. 

;  "  ■  -  / 

The  main  objectives  of  this  research  were:  (1)  Model,  through 
concept  mapping,  the  probable  decision  process  of  the  ECCO  for  the 
retasking  of  EC  assets.  (2)  Continue  the  investigation  into  the 
effectiveness  of  paper-based  storyboarding  in  determining  system 
requirements.  (3)  Investigate  the  possibility  of  using  a  computer- 
based  storyboarding  process  with  the  aim  of  determining  the 
feasibility  of  user  generation  of  system  requirements. 
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The  results  indicate  that  the  storyboarding  process  is  excellent 
for  the  unambiguous  communication  of  requirements.  There  is  every 
indication  that  computer-based  storyboarding  can  prove  to  be  even 
more  effective  by  taking  the  user  one  step  closer  to  the  actual 
system  and  may  thereby  enable  the  generation  of  system 
requirement  by  users  in  the  field. 


H 


Acknowledgement 


Every  attempt  has  been  made  to  supply  trademark  information 
about  company  names  and  products  mentioned  in  this  thesis. 
Trademark  information  was  derived  from  various  sources. 

HyperCard,  Macintosh  II,  Macintosh  SE,  MacDraw,  and  Switcher  are 
all  trademarks  of  Apple  Computer,  Inc. 


'tf ^  ■•r 


m 


DESIGN  REQUIREMENTS  FOR  A  DECISION  SUPPORT  SYSTEM  FOR 
THE  DYNAMIC  RETASKING  OF  ELECTRONIC  COMBAT  ASSETS 


I.  Introduction 


Mission:  Electronic  Combat  (EC) 


Operations  involving  the  electromagnetic  spectrum  have  long 
been  recognized  as  an  important  adjunct  to  all  military  operations. 
Examples  of  these  operations  range  from  the  radio  communications 
countermeasures  used  at  Port  Arthur  during  the  Russo-Japanese  War 
of  1904  to  the  full  range  of  electronic  combat  operations  used  by  the 
Israelis  in  their  air  operations  over  the  Baaka  Valley  of  central 
Lebanon. 

To  support  and  further  enhance  the  effective  use  of  electronic 
combat  operations  it  is  the  purpose  of  this  thesis  to  generate  an 
initial  set  of  requirements  for  the  development  of  an*  aid  to  support 
the  commander  in  the  real-time  combat  control  of  electronic  combat 
air  assets. 

AFM  1-1,  Basic  Aerospace  Doctrine  of  the  United  States  Air 
Force,  defines  Electronic  Combat  (EC)  as: 

.  .  .  the  integrated  use  electronic  countermeasures  (ECM), 
suppression  of  enemy  air  defenses  (SEAD),  and  command, 
control,  communications  countermeasures  (C3CM)  to  degrade 


or  destroy  the  enemy's  ability  to  disrupt  friendly  air  activity. 

(10:3-6,3-7) 

The  components  of  Electronic  Combat  are  defined  in  JCS  Publication 
1,  Department  of  Defense  Dictionary  of  Military  and  Associated 
Terms  (12:128,  356,  77).  Over  the  past  twenty  years,  EC  operations 
have  become  more  pervasive  and  used  on  a  larger  scale  due  to  the 
increasing  threat  of  air  defense  systems  and  its  recognized 
contribution  as  a  force  multiplier.  This  has  resulted  in  the 
development  of  dedicated  air  assets  in  the  areas  of  Electronic 
Surveillance  Measures  (ESM),  Electronic  Intelligence  (ELINT), 
Electronic  Countermeasures  (ECM),  and  Suppression  of  Enemy  Air 
Defenses  (SEAD).  Current  examples  of  such  dedicated  systems  are 
the  F-4G  Wild  Weasel,  EF-111  Raven,  EA-6B,  EH-60  HAVE  QUICK, 
RF-4  TEREC,  OV-1  Mohawk,  EC-130  Compass  Call,  and  others. 

Despite  the  recognized  value  and  need  for  these  systems,  their 
tremendous  costs,  and  the  resultant  scarcity  of  these  assets,  only  in 
the  last  few  years  has  there  been  some  preliminary  work  done  to 
formulate  a  coherent  concept  of  the  tactics  for  the  integrated 
employment  of  EC  assets,  but  even  this  has  been  limited  to  the  F-4G, 
EC-130,  and  EF-111  (7).  The  concern  over  this  deficiency,  a  subset 
of  the  more  general  concept  of  command  and  control,  is  evidenced 
by  the  65th  Air  Division  staff,  among  others,  which  is  charged  with 
the  duty  of  employing  EC  assets  within  the  NATO  Central  Region  (33; 
7;  6).  These  concerns  were  summarized  by  a  team  of  analyst  headed 

by  Mr.  Philp  Cunningham  of  the  MITRE  Corporation  who  studied  the 
taskings  of  the  65  AD  and  their  efforts  to  carry  these  taskings  out. 

Mr.  Cunningham  indicated  that  the  65  AD  staff  had  voiced  their 
concern  that  there  was  currently  no  defined  strategy  for  managing 
the  allocation  of  the  limited  EC  assets  to  support  Central  Region 
tactical  operations.  He  stated  that  the  staff  was  further  concerned 
that  the  Central  Region  lacked  the  capability  to  optimize  the 
employment  of  the  EF-111  A,  WILD  WEASEL  and  COMPASS  CALL  (8; 
15;  25). 
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With  only  the  beginnings  of  a  general  employment  concept 
emerging  it  is  not  surprising  there  is  no  formal  work  within  the  Air 
Force  known  to  this  writer  being  done  on  the  concept  of  how  FC 
forces  would  be  retasked  during  a  day's  battle  or  what  would  be 
needed  to  accomplish  retasking.  Retasking  is  the  assigning  of  an 
asset  to  a  mission  when  there  has  been  no  prior  planning  for  that 
possibility.  This  differs  from  an  alternate  mission  in  that  an 
alternate  mission  was  planned  for  prior  to  the  flight  as  a  possible 
mission  if  the  primary  mission  was  not  pursued.  The  question  of  the 
employment  and  retasking  of  EC  assets  is  basically  a  question  of 
command  and  control,  though  electronic  combat  does  bring  its  own 
inherently  unique  considerations.  The  official  Department  of 
Defense  definition  of  Command  and  Control  is; 

The  exercise  of  authority  and  direction  by  a  properly 
designated  commander  over  assigned  forces  in  the 
accomplishment  of  the  mission.  Command  and  control 
functions  are  performed  through  an  arrangement  of  personnel, 
equipment,  communications,  facilities,  and  procedures 
employed  by  a  commander  in  planning,  directing, 
coordinating,  and  controlling  forces  and  operations  in  the 
accomplishment  of  the  mission  (12:77). 

It  should  be  kept  in  mind  that  within  the  overall  concept  of 
command  and  control  the  concept  of  retasking  is  as  important  as  the 
concept  of  initial  employment.  The  importance  of  retasking  is  due  to 
the  uncertain  nature  of  warfare  and  the  requirement  that  the 
commander  be  able  to  adapt  his  battle  plan  to  the  changing 
battlefield  to  win. 

[The]  primary  function  of  command  is  deploying  and 
maneuvering  forces  or  other  sources  of  potential  power  to  be  in 
the  best  possible  position  to  exploit  opportunities  as  they  arise. 
This  function  can  be  viewed  as  controlling  the  power 
distribution  (29:51). 

The  command  and  control  process  of  retasking  clearly  reflects  the 
application  of  the  principles  of  Mass,  or  concentration  of  force,  and 


Maneuver.  These  principles  of  war  are  no  less  true  in  the  air  than 
they  are  on  the  ground. 

Today's  battlefield  commander  requires  the  assistance  of  an 
extensive  staff  due  to  the  complex  problems  he  faces.  With  the 
recognized  need  of  employing  electronic  combat  assets  as  a  unified 
mission  area  there  is  an  obvious  need  to  advise  the  commander  as  to 
the  best  use  of  these  forces.  This  requirement  is  being  met  by  the 
establishment  of  the  Electronic  Combat  Coordination  Officer  (ECCO) 
training  course  at  the  USAF  Electronic  Warfare  School,  Mather  AFB 
(28).  The  ECCO  must  be  able  to  advise  the  commander  over  all 
phases  of  the  command  and  control  cycle.  What  capabilities  does  the 
ECCO  require  to  fulfill  the  role  of  command  advisor? 


Com mand  and  Control:  The  Required  Capabilities  of  the 
Electronic  Combat  Coordination  Officer  (ECCO) 


The  process  of  command  and  control  has  been  modeled 
extensively  in  the  attempt  gain  an  indepth  understanding  of  its 
overall  functioning.  Work  has  been  done  in  this  area  by  Orr,  Levis 
and  Athans,  Lawson,  and  others  (29:26-43;  24;  29:24-25).  In  this 

study,  Orr's  representation  will  be  used  because  it  provides  an 
adequate  representation  of  the  command  and  control  process  and 
basically  reflects  the  other  models. 

Retasking,  as  explained  above,  is  but  one  representation  of  the 
command  and  control  process,  requiring  all  its  various  stages. 
Retasking  requires  the  same  command  and  control  functions  as  the 
initial  employment  of  assets  including  the  tasking  of  specific  assets 
against  specific  missions  to  attain  desired  levels  of  effectiveness  as 
measured  by  some  evaluation  system.  Retasking  is  therefore  the 
command  and  control  process  forced  into  a  time  compressed  cycle. 
The  lack  of  an  ability  to  retask  is  not  unique  to  the  control  of  EC 


Taken  from  Orr  p.27 


Figure  1.  Orr's  Conceptual  Combat  Operations  Process  Model 


assets  but  afflicts  all  other  missions  and  assets,  further  indicating 
that  this  is  not  a  problem  unique  to  EC  but  a  function  of  command 
and  control  in  general.  This  deficiency,  from  the  aspect  of  the 
commander's  ability  to  shape  and  modify  the  battle  with  the  advent 
of  new  information,  means  that  various  EC  assets,  though  available, 
would  be  left  unused  or  needlessly  endangered,  thus  violating  the 
principles  of  mass,  economy  of  force,  and  maneuver.  These 
violations  are  to  a  great  degree  currently  unavoidable  due  to  the 
limited  time  available,  lack  of  adequate  communications  capabilities, 
and  support  requirements  necessary  to  plan  and  implement  a  new 
mission  (33;  7;  6).  The  tactical  aircrew  employed  on  a  combat 

mission  on  NATO's  Central  European  front  is  faced  with  very  limited 
time  before  they  must  be  aborted  or  are  irrecoverably  committed  to 
their  initial  take-off  tasking  and  a  demanding,  not  to  say  lethal, 
environment  that  commands  their  undivided  attention.  To  attempt 
to  retask  an  aircrew  under  these  circumstances,  even  if  the  control 


agency  were  to  read  the  new  mission  information  to  the  crew, 
assuming  an  ECM-free  environment,  would  prove  disastrous  due  to 
the  demands  on  the  crew’s  time  to  mentally  digest  the  new 
information,  coordinate  with  others  in  their  group,  reconfigure  their 
equipment,  a  myriad  of  other  absolutely  necessary  requirements, 
and  still  fly  the  aircraft  while  surviving  enemy  assault.  As  a 
consequence  of  these  difficulties,  any  modifications  to  today's  air 
mission  is  generally  limited  to  insignificant  alteration  of  the  basic 
mission  or  thoroughly  planned  and  understood  alternate  missions. 
The  byword  of  the  day  is  "Keep  it  simple,  stupid."  This  leaves 
today's  air  commander  little  better  off  than  the  commanders  of  the 
pre-Alexander  period  over  2300  years  ago. 

As  stated  above,  the  practice  of  retasking  EC  assets  in  the 
current  command  and  control  environment  is  not  a  viable  option.  To 
give  the  commander  the  flexibility  inherent  in  the  concept  of 
retasking,  using  Orr's  model  as  a  guide,  the  command  and  control 
system  would  need  to  be  enhanced  to  give  the  ECCO  the  following 
capabilities: 

1)  Monitor  the  progress  of  the  battle, 

2)  Recognize  the  development  of  a  problem, 

3)  Assess  the  impact  of  the  problem  on  the  overall  mission, 

4)  Plan  for  a  new  mission  in  response  to  the  problem  or  the 
development  of  an  opportunity, 

5)  Develop  the  new  aircraft  mission  plans, 

6)  Communicate  and  coordinate  the  retasking, 

7)  Monitor  and  control  the  implementation  of  the  change. 
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Monitor  the  Battle's  Progress. 

[The]  history  of  command  in  war  consists  essentially  of  an 
endless  quest  for  certainty--certainty  about  the  state  and 
intentions  of  the  enemy's  forces;  certainty  about.. .the 
environment  in  which  war  is  fought,  and,  last  but  definitely 
not  least,  certainty  about  the  state,  intentions,  and  activities 
of  one's  own  forces  (45:264) 

The  Electronic  Combat  Coordination  Officer  must  first  be  able  to 
assess  the  status  of  the  current  battle  at  many  levels  to  include  the 
state  of  the  various  EC  missions.  This  capability  is  Orr's  SENSE 
function  which  has  the  goal  of  providing  continuous  data  on  the  state 
of  the  environment  as  supplied  by  various  sensors  (29:28).  This 
function  is  primarily  a  result  of  real-time  intelligence  which  at  this 
stage  in  the  command  and  control  process  model  is  still  a  collection  of 
data  and  not  yet  processed  to  produce  a  complete  picture  of  the 
battle.  Yet  despite  its  raw  form,  this  stage  is  like  all  the  other  stages 
in  that  without  it  the  commander  is  ultimately  blind  and  can  do  little 
to  form  the  battle  to  his  advantage.  The  ability  to  provide  this  data 
is  continuing  to  take  shape  in  the  Joint  STARS  program,  the 
CONSTANT  SOURCE  program,  the  E-3A  AWACS  program,  and  various 
other  programs  which  are  essential  for  gathering  and  distributing  the 
varied  and  time-sensitive  data  necessary  to  enable  the  later 
presentation  of  an  accurate  and  complete  picture  of  the  battlefield 
(or  at  least  as  complete  as  is  possible  in  war)  (13;  14).  While  this 

step  is  essential  to  the  commander's  ability  to  ascertain  the  status  of 
fhe  battlefield,  as  Levis  and  Athans  point  out  in  their  review  of 
command,  control,  and  communications  (C3)  theory,  this  is  only 
data  and  not  yet  information  (24:3).  The  transformation  of  data  into 
information  is  the  process  of  interpreting  the  data  and  forming  a 
human  impression  of  its  meaning.  This  transformation  occurs  in  the 
next  step  of  Orr's  model  which  he  entitles  PROCESS. 

Recognize  Deviations:  Genesis  of  a  Problem.  The  ECCO  must 
be  able  to  determine  that  a  significant  change  or  deviation  from  the 
planned  EC  support  mission  has  occurred.  The  determination  of  a 


* 


e 


significant  change  requires  that  there  be  an  ability  to  compare  the 
goal  state,  as  set  forward  by  the  attack/support  plan,  and 
implications  of  the  current  environment.  This  comparison  capability 
implies  knowledge  of  the  critical  requirements  and  resources  as 
determined  in  the  original  construction  and  tasking  of  the  EC  support 
package.  This  also  implies  the  ability  of  the  staff  officer  receiving 
this  information  to  evaluate  the  change  in  relation  to  the 
commander's  mission  goals  and  priorities  to  determine  if  the  change 
constitutes  a  true  deviation  or  is  it  within  acceptable  bounds.  Much 
of  this  can  be  done  using  automated  computer  comparison  and 
alarming,  indicating  such  things  as  the  failure  of  a  flight  to  make  a 
route  point  within  a  mission-dependent  time  window. 

The  details  of  having  the  general  ability  to  do  dynamic  mission 
assessment  means  having  the  specific  capability  to  gather  real-time 
knowledge  on  both  the  threat  environment  and  the  complete  attack 
force  package,  including  supporting  EC  assets.  This  real-time 
knowledge  requires  both  secure,  reliable,  survivable,  real-time 
monitoring  of  all  aircraft  and  feedback  from  aircraft  and  ground 
support  sites.  This  capability  currently  exists  in  an  embryonic  stage 
in  the  initial  efforts  to  modernize  both  the  USAF  and  NATO  Tactical 
Air  Control  System  (TACS)  as  well  as  the  initial  fieldings  of  the  Joint 
Tactical  Information  Distribution  System  (JTIDS)  (18;  46;  35;  20). 

Without  these  improvements  to  operate  in  the  ECM  environment  of 
the  future  battlefield,  this  information  will  not  be  available  and  the 
commander  will  continue  to  be  blind  to  the  air  battle. 

An  example  of  this  requirement  would  be  a  detected  change  in 
the  threat  environment  which  analysis  shows  would  result  in  a 
higher  projected  attrition  rate.  In  the  next  step,  assessment,  a 
comparison  of  the  originally  stated  requirements  and  limitations  for 
the  mission  would  show  that  the  new  attrition  level  is  not  greater 
than  the  level  that  was  deemed  unacceptable  or  that  will 
significantly  impact  the  ability  of  the  air  forces  to  pursue  future 
objectives.  Consequently,  no  mandatory  action  is  required,  though 


if  other  EC  support  assets  become  available  they  could  be  used  here 
if  this  mission  has  a  higher  priority  than  other  missions  also  being 
executed. 

With  respect  to  Orr's  model,  the  process  has  now  moved  on  to 
the  step  entitled  PROCESS  where  the  data  is  analyzed  and  put  into  a 
useful  form  for  humans.  The  data  can  now  be  termed  information  as 
it  can  be  used  to  further  human  understanding  of  the  environment 
and  the  building  of  knowledge  (24:3).  In  the  context  of  this 
problem,  the  information  will  generally  be  presented  in  a  graphic 
form  such  as  a  computer  screen  display  of  a  map  of  the  battlefield 
with  selectable  information. 

Assess  the  I mpact  of  the  Deviation.  Still  within  the  PROCESS 
stage  of  Orr's  model,  the  next  step  the  ECCO  must  accomplish  is 
evaluating  the  impact  of  the  change  on  the  outcome  of  the  mission, 
the  future  capability  of  the  EC  forces,  and  in  relation  to  the 
commander's  current  and  future  goals.  The  outcome  of  this 
assessment  is  a  determination  that  either  some  action  need  be  taken, 
such  as  implementing  one  of  the  alternatives  or  possibly  generating  a 
completely  new  tasking  (retasking),  or  that  the  deviation  does  not 
impact  current  operations  enough  to  require  any  intervention. 

An  attack  plan  is  generated  using  several  planning  boundaries. 
The  first  is  the  commander's  guidance  which  yields  the  overall 
objectives  of  the  air  campaign.  As  a  result  of  this  guidance,  target 
lists  and  desired  levels  of  target  destruction  are  developed.  An 
overall  understanding  of  unacceptable  campaign  attrition  levels  is 
also  developed  by  implication  due  to  the  need  to  pursue  long-run 
mission  objects.  The  second  constraint  is  the  available  resources. 
Based  on  these  two  boundaries,  the  specific  combination  of  aircraft 
and  weapon  is  prepared  to  include  a  supporting  cast  of  air  refueling 
aircraft,  EC  aircraft,  fighter  escorts,  etc.  This  supporting  cast 
primarily  affects  the  attrition  level  of  the  package  but  this  in  turn 
impacts  the  realized  destruction  level  of  the  target  since  a  lower 
attrition  level  going  into  the  target  will,  in  a  general  sense,  yield  a 


greater  destructive  force  which  can  be  applied  to  the  target. 

Therefore,  the  impact  of  deviations  in  the  planned  mission  will 
generally  fall  into  these  two  major  categories: 

1)  target  destruction, 

2)  projected  package  attrition  (34;  32). 

Theoretically,  even  changes  such  as  the  loss  of  a  recovery  base 
impact  the  projected  attrition  rate.  It  has  this  kind  of  impact 
because  the  support  required  to  put  sorties  in  the  air  is  no  longer 
there,  aircraft  now  fly  longer  legs  to  accomplish  a  mission  and 
therefore  burn  more  of  the  remaining  fuel  to  accomplish  the  same 
mission,  thus  decreasing  the  total  number  of  sorties  that  can  be 
flown,  and  so  on. 

Of  course,  the  deviations  the  ECCO  would  be  primarily 
interested  in  would  be  ones  that  impact  the  lethality  of  the  direct 
threat  environment  such  as  the  loss  of  a  flight  of  F-4G  Wild  Weasels 
or  the  sudden  relocation  of  an  SA-iO  SAM  to  the  middle  of  the 
ingress  route.  The  ECCO  must  have  the  capability  to  analyze  how 
these  changes  affect  the  mission,  determine  if  the  impact  is 
significant  in  relation  to  established  goals  and  constraints,  and  if 
there  is  time  to  implement  a  corrective  action  or  only  time  for  a 
GO/NO  GO  decision.  If  there  is  time,  he  must  then  ascertain  whether 
a  prearranged  alternate  plan  will  solve  the  problem  or  whether  an 
entirely  new  plan/retasking  are  required.  If  none  of  the  preplanned 
alternatives  provide  a  solution,  it  falls  to  retasking  to  give  the 
commander  the  flexibility  to  respond  to  the  challenge  or  opportunity 
that  presents  itself.  It  is  retasking  that  this  study  looks  to  support, 
as  stated  at  the  beginning  of  this  chapter,  through  the  generation  of 
an  initial  set  of  requirements  for  a  decision  support  system  (DSS). 
Perhaps  the  major  capability  required  of  the  decision  aid  for  the 
viability  of  real-time  retasking  is  the  ability  of  the  system  to  support 
the  rapid  planning  and  evaluation  of  alternate  missions  in  the 
generation  of  a  single  new  mission  for  rctasking. 


Planning  for  Real  -  Time  Retasking.  Planning  for  real-time 
retasking  differs  very  little  from  that  of  normal  planning  except  that 
what  today  takes  several  hours,  looking  only  at  a  few  aircraft,  must 
be  done  in  just  a  few  minutes.  In  actuality  the  problem  of  planning 
the  mission(s)  is  somewhat  simplified  by  the  fact  that  the  planner  is 
faced  with  many  constraints  to  his  flexibility  and  thus  is  left  with 
only  a  few  options.  The  assets  available  to  accomplish  the  new  plan 
are  limited  to  the  few  aircraft  on  alert,  either  airborne  or  on  the 
ground,  which  have  the  capabilities  to  meet  the  mission  needs  or 
those  few  aircraft  that  are  left  from  an  attack  force  package  that  was 
cancelled  for  some  reason.  (The  first  case  is  substituting  planned 
spare  assets  to  meet  a  loss  while  the  latter  case  is  that  of  an 
unexpected  excess  of  assets  in  position  to  be  used.)  It  is  very  likely 
that  fighter-type  EC  assets  would  require  air  refueling  prior  to 
joining  a  new  attack  package.  Therefore,  fighter-type  EC  assets 
would  drop  from  usefulness  because  of  the  delay  this  would 
probably  impose  on  the  attack  force  and  the  constraint  that  the 
retasked  EC  assets  will  not  impede  the  attack  force.  Thus  the 
planner's  options  are  reduced  still  further. 

Once  the  filtering  effect  of  all  these  and  other  constraints  are 
complete,  as  conducted  by  the  ECCO  and  assisted  by  the  aid  through 
the  use  of  checklists  and  other  memory  aids,  then  the  actual 
generation  of  the  new  missions  would  be  required  to  be  supported. 

Generation  of  Alternate  Retasking  Plans.  The 
generation  process  of  alternative  missions  can  follow  a  variety  of 
paths,  anywhere  from  a  fairly  structured  path  to  one  of  essentially 
ad  hoc  manipulation.  In  the  area  of  retasking,  we  are  concerned 
about  the  retasking  of  a  limited  number  of  supporting  EC  assets 
against  a  limited  number  of  options  such  as  NO  GO  or  supporting  one 
of  a  few  missions.  Consequently,  the  limited  missions  which  the  EC 
assets  will  be  supporting  and  the  other  constraints  the  ECCO  will  be 
operating  under  will  lend  a  ready  structure  to  the  feasible  plans. 
None-the-less,  it  has  been  suggested  that  under  high  stress 


conditions  "canned"  templates  of  alternate  plans  can  help  avoid 
serious  mistakes  (17:951;  4:466).  Templating  could  be  done  for  a 

wide  range  of  easily  imagined  and  plausible  conditions  in  terms  of 
the  number  and  types  of  EC  assets  you  must  retask.  These  templates 
could  then  be  stored  in  an  aid  to  be  recalled  as  needed  with  all  the 
applicable  memory  aids  and  software  systems  to  further  ease  the 
replanning/retasking  procedure. 

The  next  consideration  would  be  to  determine  in  what 
other  attack  group  the  excess  assets  should  be  used,  if  the  assets' 
original  attack  force  had  been  aborted,  or  which  group  could  best 
afford  the  loss  of  assets  if  a  higher  priority  force  had  lost  the  service 
of  some  of  its  EC  assets.  This  could  to  be  done  using  an  attrition 
analysis  model  and  "what  if'ing  the  EC  support  package  for  each 
group  accordingly. 

Of  course  all  this  would  be  guided  by  the  commander's 
goals  and  guidance  and  the  resulting  target  priorities.  This 
information  should  be  available  to  the  ECCO  (6;  34).  Further 

planning  information  needed  in  the  process  would  be  concerning 
both  the  aircrafts'  and  the  EC  systems'  capabilities,  limitations,  and 
operational  considerations,  such  as  not  putting  one  type  of  EC 
aircraft  too  close  to  another  particular  type  of  EC  aircraft.  These 
memory  aids  should  also  extend  to  areas  such  as  rules  of  engagement 
as  these  will  definitely  impact  planning. 

To  facilitate  a  more  complete  perspective  of  the  plans 
being  developed  and  an  understanding  of  exactly  the  impact  the 
analysis  models  are  indicating,  the  ECCO  should  have  as  a  master 
working  screen  an  overview  of  the  geographical  area  with 
representation  of  the  enemy  Integrated  Air  Defense  System  (IADS). 
This  geographical  overview  screen  should  have  all  the  major 
characteristics  of  the  IADS  such  as  command  connectivity,  radar 
coverage,  and  missile  range  as  selectable  options  (6).  This  logically 
extends  to  other  areas  as  well  such  as  representations  of  attack 


groups,  the  particular  assets  being  retasked,  airspace  usage  codes, 
and  other  major  factors  that  impact  on  retasking. 


Evaluation  and  Selection  of  Alternates.  The  evaluation 
of  the  generated  alternate  retasking  plans  should  be  relatively 
straight-forward  as  this  would  be  based  on  accomplishing  the 
commander's  objectives  while  maintaining  low  attrition.  This  could 
be  more  finely  and  objectively  measured  using  a  multiple  criteria 
decision  making  algorithm. 

Mission  Planning.  Under  normal  mission  planning  conditions, 
with  some  variations  depending  on  the  type  of  weapon  system, 
staffs  above  the  squadron  develop  general  plans,  in  response  to 
their  commander's  taskings  or  a  higher  headquarters,  while 
squadron  crews  do  the  detailed  planning  for  each  aircraft  sortie. 

For  real-time  mission  planning  in  preparation  for  retasking 
most  of  what  the  crew  normally  does  must  be  accomplished  for  them 
and  then  forwarded  to  them  while  they  are  in  flight.  For  Electronic 
Combat  aircraft  and  crews  this  would  mean  that  their  route  and  all 
its  navigation  points/times  would  need  to  be  selected,  calculated, 
prepared,  and  transmitted  for  both  on-board  encoding  into  the 
aircraft's  navigation  equipment  and  presentation  to  the  crew.  The 
mission  area  and/or  target(s)  information  would  also  have  to  be 
prepared  and  loaded  into  the  appropriate  aircraft  systems  as  well  as 
presented  to  the  crew  for  their  study.  This  is  critical  for  mission- 
configurable  aircraft,  such  as  the  EC-130  and  EF-111,  and  the  F-4G 
Wild  Weasel  which  adjusts  its  tactics  depending  on  the  surrounding 
terrain  for  tasked  targets.  Other  information  would  also  need  similar 
preparation  and  handling  such  as  new  ingress/egress  routes,  call 
signs,  iff/sif  codes,  and  so  on. 

Getting  this  data  to  the  crews  and  coordinating  with  all  affected 
parties  would  be  the  final  step  required  of  the  commander  and  his 
staff  to  affect  real-time  retasking  of  the  EC  assets. 


s  s 


Retaskine:  Executing  the  New  Mission. 


Communications.  The  new  tasking  must  be 
communicated,  its  impact  coordinated,  and  acknowledgement  of  the 
receipt  of  these  changes  obtained.  This  requires  a  secure,  reliable, 
survivable,  high  data  rate  communications  link,  which  generally 
excludes  voice  communications  from  much  more  than  a  warning 
notice  of  incoming  information  and  acknowledgement  of  its  receipt. 

It  also  requires  a  clear,  understandable,  unambiguous,  high-transfer 
rate  representation  for  the  crew  which  eliminates  audio  or  written 
form  as  each  is  too  slow  to  cognitively  assimilate.  The  most  likely 
format  is  a  graphics  representation. 


This  also  requires  the  capability  for  in-flight 
reprogramming  of  on-board  electronic  combat  equipment, 
navigation  computers  and  various  other  on-board  gear  that  currently 
can  only  be  done  on  the  ground  or  requires  too  much  of  the  crew's 
time  for  it  to  be  a  practical  in-flight  crew  function  during  combat 
operations. 


In-flight  retasking  further  implies  that  all  those  who 
would  be  addressed  during  normal  mission  planning  will  have  to  be 
informed  of  the  change. 


Retasking  also  requires  that  coordination 
be  done  with  all  other  groups  impacted  by  the  new  mission.  This 
includes  the  new  forces  to  be  supported,  air  refueling  tanker 
support,  ground  Air  Defense  Artillery  (ADA),  defensive  air 
command  centers,  and  others.  Airspace  management  is  a  critical 
area  that  must  be  addressed.  The  ability  to  dynamically  retask 
assets  requires  that  coordination  be  done  to: 


1)  allow  the  transit  of  former  "hot"  areas,  such  as  ADA 
free  fire  areas  (SHORAD  is  undenighably  a  major  problem)  or 
artillery  fire  space. 


2)  enable  the  rendezvous  with  the  new  attack  force. 


3)  inform  SOCs  and  obtain  clearance, 

4)  nullify  potential  delays  of  the  attack  package, 

5)  minimize  the  adverse  impact  on  intelligence  gathering 
missions  thereby  not  blinding  the  commander's  eyes  and  ears. 

In  addition,  the  deconfliction  of  frequency  is  badly  needed  to 
minimize  resources  confliction.  This  is  a  major  concern  that  needs  to 
be  an  integral  function  of  the  planning  and  coordination  process  and 
which  has  been  very  little  and  inadequately  considerations  for 
manual  operations  (6;  34). 

While  retasking  deals  favorably  with  the  commander's 
flexibility,  it  also  holds  a  strong  potential  for  disaster  by  violating 
the  principle  of  Simplicity  unless  the  forces  are  trained  and  practiced 
for  this  process. 

Monitor  Results.  Once  the  retasking  and  coordination  has  been 
done  and  is  being  executed  the  cycle  starts  again  with  the 
commander  looking  for  that  desired  opportunity  to  move  forces  at 
the  decisive  moment  to  the  critical  location. 


Research  Problem 


The  major  responsibility  of  the  ECCO  would  be  to  advise  the  air 
commander,  assumed  to  be  a  NATO  air  commander  at  the  AAFCE 
level,  on  a  satisfactory  plan  for  the  retasking  of  EC  assets  to  respond 
to  an  unexpected,  and  therefore  unplanned  for,  occurrence  during 
the  execution  of  the  air  war.  While  this  unexpected  change  could 
stem  from  a  myriad  of  sources,  the  ECCO  must  be  able  to  carry  out 
this  charter  regardless  of  the  source  and  be  able  to  assess  the 
advantages,  the  disadvantages,  the  impact  on  the  commander 


objectives,  and  to  some  extent  the  long  term  impact  on  the  EC  forces 
of  retasking.  He  then  must  be  able  to  develop  and  recommend  a 
course  of  action  in  a  very  time  compressed  environment  when 
dealing  with  a  very  complicated,  unstructured,  and  multivariable 
problem. 


Research  Objective 


The  primary  objective  of  this  research  is  to  develop  an  initial 
set  requirements  for  a  decision  support  system  (DSS)  designed  to  aid 
the  ECCO  charged  with  advising  the  AAFCE  commander  on  the  real 
time  dynamic  retasking  of  EC  assets. 

Subsidiary  objectives  which  have  been  identified  as  necessary 
to  accomplish  the  overall  objective  are: 

1.  Identify  the  EC  planning,  tasking,  and  retasking  decision 
processes. 

2.  Identify  the  kernel  processes  of  the  retasking  process. 

3.  Identify  the  major  inputs  to  the  retasking  process. 

4.  Identify  those  processes  that  are  to  be  supported  by  a  data 
base  or  a  model. 

5.  Identify  the  types  of  information  and  key  fields  needed  to 
build  the  DSS  data  base. 

6.  Identify  the  processes  that  require  model  simulation,  what 

information  the  model  is  required  to  generate,  and  how  levels  of 

value  or  measures  might  be  established  to  value  the  effectiveness  of 
EC 


7.  Develop  the  key  presentations  and  information  connectivity 
to  enable  the  decision  maker  to  assess  alternate  EC  configurations 
and  proposed  taskings. 

8.  Develop  an  evaluation  criteria  and  management  structure 
for  the  evolutionary  design  of  the  DSS. 


Scope.  Limitations,  and  Assumptions 


This  study  will  only  consider  the  retasking  of  EC  assets. 
Further,  beyond  the  communications  needed  to  affect  the 
rendezvous  between  the  EC  and  attack  force  to  be  supported,  it  is 
assumed  that  the  attack  force  will  not  be  required  to  take  any  other 
action  than  it  had  originally  planned  for.  Therefore,  the  attack  force 
will  not  have  to  delay  its  PLOT  penetration  time,  its  strike  times,  or 
any  other  of  its  activities  to  accommodate  the  EC  retasking. 

The  scope  of  this  study  is  the  identification  of  an  initial  set  of 
requirements  necessary  to  do  the  rapid  prototyping  and  adaptive 
design  of  a  DSS  to  aid  the  Electronic  Combat  Coordination  Officer  in 
advising  the  Allied  Air  Forces  Central  Europe  (AAFCE)  commander  on 
the  dynamic  retasking  of  EC  assets  during  mission  execution. 

Therefore,  no  system  or  software  will  be  developed  for  this 
effort. 

It  is  assumed  that  the  intelligence  and  communication 
capabilities  described  earlier  are  in  existence. 


II.  Methodolo 


Introduction 


The  challenge  of  assisting  the  ECCO  in  the  real-time  retasking  of 
EC  assets  requires  that  some  method  be  used  to  identify  the 
requirements  for  a  decision  aid  to  this  process.  The  nature  of 
electronic  combat  is  complex  and  fluid,  changing  over  time  with  new 
technology  as  well  as  with  the  introduction  of  new  tactics.  This 
demanding  combat  environment  and  its  associated  decision  process 
means  that  not  all  of  the  pertinent  factors  can  be  predetermined  and 
thereby  programed  into  a  one-step  rescheduling/  retasking  system. 
Additionally,  due  to  the  complex  and  constantly  changing  nature  of 
electronic  combat,  neither  is  it  obvious  at  the  beginning  of  an 
assistance  program  what  functions  this  system  must  be  able  to 
support  now  or  what  functions  it  must  support  in  the  future.  As  a 
result  of  the  complex,  multidimensional,  and  ever-changing  nature 
of  EC,  any  support  which  is  chosen  to  aid  the  ECCO  must  actually 
support  the  ECCO's  creative  decision  process.  In  light  of  these 
requirements,  a  Decision  Support  System  (DSS)  was  the  methodology 
selected  to  aid  the  ECCO.  Concept  maps,  storyboards,  and  feature 
charts  were  selected  to  identify  both  the  initial  requirements  of  the 
DSS  and  the  subportion  of  the  DSS  to  be  implemented.  Adaptive 
design  supported  by  storyboarding  was  chosen  for  the  continued 
identification  of  user  requirements  to  enable  the  constructive, 
timely,  and  on-going  evolution  of  the  DSS. 


Decision  Support  Svstem  (DSS) 


What  ij^  a  DSS?  A  decision  support  system  is  defined  by 
Valusek  as  a  system,  either  manual  or  automated,  that  supports  the 
cognitive  processes  of  judgement  and  choice.  Additionally,  he 
indicates  that  a  DSS  is  characterized  by  a  concern  for  decision¬ 
making  effectiveness  as  opposed  to  a  favored  solution  technique, 
process  flexibility,  an  emphasis  on  the  graphic  presentations  of 
information,  enabling  the  decision  maker  to  conduct  "what  if" 
sensitivity  analysis,  tying  together  both  modelling  and  data  base 
capabilities,  incorporating  subjective  assessments,  and  an  ongoing 
evolutionary  implementation  (43).  Watson  and  Hill  define  a  DSS  as 
.  .  .  an  interactive  system  that  provides  the  user  with  easy  access  to 
decision  models  and  data  in  order  to  support  semi-structured  and 
unstructured  decision-making  tasks"  (47:82).  They  also  assert  that 
to  fully  qualify  as  a  DSS  the  system  must  exhibit  characteristics 
which  are  drawn  from  Sprague  and  Carlson.  These  characteristics 
include: 

1)  decision  support  systems  tend  to  be  aimed  at  less 
structured,  unspecified  problems; 

2  they  combine  the  use  of  models  or  other  analytic  techniques 
with  traditional  data  management  functions; 

3)  they  focus  on  an  interactive  process  that  is  easy  to  use  even 
for  people  not  accustomed  to  using  computers; 

4)  they  emphasize  flexibility  and  adaptability  to  adjust  to  a 

changing  environment  and  the  decision-making  approach  of  the  user 
(47:82;  39:6). 

Alavi  and  Napier  also  define  a  DSS  as  a  system  designed  with  the 
primary  purpose  of  supporting  the  decision  maker  in  the  judgement 


process  as  the  decision  maker  deals  with  semislruclured  or  poorly 
defined  problems  (3:21). 

An  important  point  concerns  the  meaning  of  the  terms 
semistructured  or  unstructured  which  play  major  functions  in 
defining  the  type  of  decision  process  environment  that  a  DSS  should 
support.  Sprague  and  Carlson  use  Simon's  definition,  calling  a 
problem  unstructured  because  of  its  novelty,  the  time  constraints 
facing  the  decision  maker,  the  lack  of  knowledge  about  a  problem  or 
the  lack  of  the  certainty  about  that  knowledge,  the  large  search 
space  to  either  define  the  problem  or  identify  possible  solutions  or 
both,  the  intuitive  inputs  required,  or  other  reasons  (39:94). 

DSS  Functional  Components:  PPM.  Functionally,  a  DSS  is 
made  up  of  three  major  components,  the  data  base  management 
component,  the  model  base  component,  and  the  dialog  component. 
This  is  abbreviated  DDM.  As  a  system,  these  three  components  are 
tied  together  and  interact  with  one  another  to  provide  a  powerful 
and  flexible  decision  support  system  for  the  decision  maker.  The 
data  subsystem  has  the  commonly  accepted  DBMS  capabilities  to 
manipulate  data  but  is  also  made  up  of  a  richer  variety  of  data 
sources  and  is  generally  a  dedicated  system  as  opposed  to  it  being 
just  a  portion  of  the  system's  general  operating  system.  The  model 
subsystem  allows  the  user  the  capability  to  easily  create  models, 
catalog  and  maintain  a  range  of  models,  to  interrelate  models  with 
appropriate  linkages  through  the  data  base,  and  manage  the  model 
base  as  is  done  with  the  data  base.  The  dialog  subsystem  is  the 
interface  between  the  user  and  the  system.  Unless  the  user  is 
comfortable  with  this  pr  ‘  of  the  DSS  he  will  not  use  any  part  of  the 
DSS.  The  dialog  compr  a  ould  handle  a  variety  of  input  devices, 
present  data  in  a  varie  of  r  mners  at  the  selection  of  the  user, 

provide  a  variety  of  st;  „  or  a  flexible  style  to  accommodate  the 
user,  and  provide  flexi  ’  ;  support  for  the  user's  knowledge  base 
(39:28-33). 
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Therefore,  a  DSS  is  a  system  which  supports  the  decision 
making  process  in  arriving  at  judgements  or  solutions  in  loosely  or 
semistructured  problem  environments.  A  DSS  has  various 
characteristics  as  listed  above,  but  above  all  the  most  important  is 
that  a  DSS  supports  the  process  of  decision  making  as  opposed  to 
being  the  process  itself. 

W hy  DSS?  Selection  of  the  tool  by  which  a  user  is  assisted  in 
solving  a  problem  will  determine  to  a  large  degree  how  successful 
that  user  will  be  in  addressing  the  challenges  that  face  him. 

Therefore,  it  is  important  that  the  characteristics  of  the  tool  the  user 
is  supplied  with  match  the  demands  of  the  environment.  This  in 
turn  requires  that  the  environment  be  carefully  analyzed  to  properly 
determine  its  true  characteristics. 


The  EC  retasking  environment  is  characterized  by; 

1)  severe  time  constraints, 

2)  high  time  stress  levels, 

3)  labor  intensive  calculations  to  determine  items  such  as  the 
projected  effectiveness  of  various  types  of  electronic 
countermeasures  against  different  targets, 

4)  an  appreciation  of  the  unpredictable  synergistic  effects  of 
employing  different  types  of  EC  aircraft  in  support  of  an  operation 
and  the  ability  to  use  judgement  in  arriving  at  a  final  employment 
option, 

5)  the  need  to  develop  and  assess  several  different 
employment  alternatives, 

6)  and  an  environment  that  can  be  broken  into  definitive 
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parts. 


This  is  not  a  comprehensive  list  but  it  does  cover  the  major 
characteristics  and  gives  an  appreciation  for  those  other 
cliaracteristics  that  might  be  further  listed. 

When  this  characterization  of  the  EC  retasking  environment  is 
compared  against  the  definition  of  the  DSS  methodology  developed 
above,  it  can  be  seen  that  the  DSS  methodology  could  be  used  to  help 
the  ECCO  solve  the  task  of  retasking  EC  assets.  This  conclusion  can  be 
further  supported  by  using  Meador  and  Rosenfeld's  list  of 
characteristics  that  mark  a  decision  process  as  one  which  would  be  a 
good  candidate  for  the  use  of  a  DSS..  These  again  parallel  the 
characteristics  of  the  EC  reiasking  environment  (26;  164).  An 
additional  characteristic  which  might  also  be  added  is  that  the 
problem  environment  requires  several  different  types  of  analytical 
tools  to  address  the  various  aspects  of  the  problem. 

The  DSS  methodology  was  selected  to  aid  the  ECCO  as  it  best  fit 
the  requirements  as  opposed  to  any  one  problem  solving  approach. 
As  Schoeck  stated  in  his  thesis, 

...choosing  a  specific  operations  research  tool  tends  to  bind  the 
researcher,  causing  less  than  full  investigation  of  the  problem 
area  by  creating  too  many  front-end  assumptions.  DSS 
methodology  allows  a  researcher  to  explore  the  problem  from 
the  user  output  point  of  view,  unconstrained  by  the  need  for 
[particular]  solution  techniques  during  the  initial  phases  of 
problem  definition  (36:2-7). 


Adaptive 


The  key  advantage  to  a  DSS  is  its  flexibility  in  supporting  the 
problem  solving  needs  of  the  decision  maker.  A  design  process 
which  is  as  flexible  as  the  DSS  tool  it  is  to  help  build  is  needed  for  die 


DSS  implementation.  The  adaptive  design  process  fulfills  this 
requirement.  Adaptive  design  enables  the  rapid  fielding  of  a  portion 
of  the  complete  aid  so  as  to  provide  assistance  to  the  user  as  soon  as 
possible.  It  also  helps  to  insure  that  system  requirements  are 
correctly  determined  so  that  the  eventually  complete  DSS  will  have 
evolved  with  the  necessary  tools  and  capabilities  to  fulfil  its 
theoretical  potential  (19). 

What  is  adaptive  design  and  how  does  it  ensure  proper 
requirements  definition?  Design  is  the  process  of  mapping 
requirements  into  a  structure.  Adaptive  design  is  an  evolutionary 
design  process  based  on  the  concept  of  starting  small  with  a  central 
aspect  of  the  potential  DSS  and  expanding  on  that  starting  point  with 
the  system  left  in  place  with  the  user  (42:2).  In  the  traditional 
design  process  all  system  requirements  are  gathered  first  and 
"frozen"  so  that  the  complete  system  can  be  constructed.  The 
traditional  design  process  fails  to  adequately  capture  the  true  system 
requirements  due  to  several  factors.  Among  these  are  the  facts  that 
the  problem  environment  is  rapidly  changing,  users  are  unable  to 
pro'.ide  a  functional  breakdown  of  their  decision  process,  and  users 
have  been  shown  not  to  be  aware  of  what  they  need  either  now  or  in 
the  future.  A  process  is  needed  which  overcomes  these  hurdles. 
Adaptive  design  facilitates  this  by  implementing  a  single  part  of  the 
DSS  and  letting  the  user's  needs,  as  they  occur  in  the  working 
environment,  determine  what  is  to  be  added  during  the  DSS's 
stepped  expansion.  This  dynamic  design  process  enables  the  DSS  to 
meet  the  user's  evolving  needs  (9:19).  The  question  of  how  to  select 
the  initial  core,  or  kernel,  of  the  DSS  to  implement  first  and  the 
basic  configuration  of  the  system  are  at  the  center  of  this  research 
and  will  be  discussed  below. 

The  actual  adaptive  design  process  incorporates  the  traditional 
four  development  steps  (i.  e.,  requirements  analysis,  design, 
development,  implementation)  by  compressing  them  into  a  single 
step  which  is  repeated  rapidly  over  the  period  of  weeks  as  opposed 


to  years  as  is  typical  of  the  traditional  approach.  This  is  possible 
because  only  a  small  part  of  the  DSS  is  selected  by  the  user  and 
builder/designer  to  be  initially  implemented.  During  each  cycle  the 
system  is  evaluated,  modified,  and  incrementally  expanded.  After 
several  repetitions  of  the  cycle  the  system  will  become  relatively 
stable  and  the  next  major  subsystem  is  tackled.  As  mentioned 
earlier,  the  system  will  never  be  completely  stable.  This  is 
primarily  the  result  of  a  purposeful  strategy  of  the  user  and  designer 
to  accommodate  flexibility  and  changes  in  the  decision  process,  the 
environment,  improving  technology,  and  various  other  reasons 
(38:16-17;  39:15). 

The  initial  requirement  for  the  DSS  to  be  constructed,  the 
initial  subsystem  to  be  implemented,  and  the  on-going  and  evolving 
system  requirements  are  all  determined  in  the  process  illustrated  in 
Figure  2  which  illustrates  the  front-end  development  of  a  DSS. 
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Figure  2.  Requirements  Determination  During  DSS  Development 


After  the  initial  determination  that  a  problem  exists  and  the  user 
needs  some  assistance  in  a  decision  process,  concept  mapping  is  used 
to  identify  the  structure  of  the  decision  process  and  what  part  of  that 
process  might  be  aided  by  a  DSS.  Feature  charts  show  the 
information  connectivity  of  the  process  while  storyboards  are  used 
iteratively  to  flesh  out  the  detailed  requirements  of  the  DSS  prior  to 


full  implementation  which  by  definition  irrevocably  commits  the 
limited  resources  of  the  organization.  Each  of  these  tools  will  be 
discussed  further  below.  This  process  continues  through  the 
evaluation  of  the  system,  determination  of  further  requirements 
using  storyboarding,  and  implementation  of  the  approved 
storyboards  as  functioning  capabilities.  The  genesis  for  this 
evolution  and  expansion  is  the  "hook  book."  The  hook  book  is  a 
repository  of  ideas  for  the  desired/needed  enhancements  to  the  DSS. 
These  are  collected  throughout  the  design/development  process  and 
thereafter  as  the  system  is  in  use  (42:10).  Throughout  this  process 
the  system  is  able  to  respond  to  the  long  term  needs  of  the  user  by 
adapting  to  the  problem  space  (38:17).  As  such,  the  adaptive  design 
process  forces  the  user  and  designer/builder  to  continually  assess 
the  adequacy  of  the  DSS  in  supporting  the  needs  of  the  user  and  how 
it  might  evolve  to  meet  those  needs.  This  continuing  analysis 
enables  the  user  to  more  truly  determine  the  basic,  on-going 
requirements  of  the  DSS  and  overcome  requirements  determination 
problems  like  recency  (recency  is  remembering  first  the  last  event, 
in  this  case  a  problem,  that  was  added  to  memory  regardless  of  its 
true  priority  of  importance)  (39:16;  2:583). 


Concept  Maps 

Concept  mapping  was  used  to  identify  and  select  that  part  of 
the  ECCO's  retasking  decision  process  that  was  to  be  aided  first  by  the 
decision  support  system.  A  concept  map  is  a  graphic  depiction  of  the 
hierarchial  interrelationships  among  concepts  of  some  given  subject. 

It  uses  nodes  to  represent  the  concepts  which  are  elements  of  the 
overall  subject  and  descriptive  linking  words  on  connecting  arcs  to 
show  their  interrelations  (27:44-85).  In  this  case  the  subject  of 
interest  was  the  decision  process  of  the  ECCO  when  faced  with  the 
retasking  of  EC  assets  (Examples  of  these  are  in  Appendix  A). 
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Concept  mapping  aids  the  designer/builder  in  the 
determination  of  what  subportion  of  the  decision  process  to  aid  by 
providing  a  quick  bounding  of  the  problem  space  and  a  general 
understanding  of  a  problem’s  interrelated  factors  as  well  as  their 
structure.  McFarren  concludes  in  his  thesis  that  "...  concept  maps 
created  by  the  expert  capture  the  key  concepts  of  the  problem 
and/or  the  elements  of  the  decision  process  used  by  the  expert" 
(27:68).  This  mapping  thereby  helps  the  designer/builder  in 
identifying  the  key  concepts,  the  crucial  nodes  of  the  hierarchy,  and 
consequently  aids  in  selecting  a  part  of  the  decision  process  to 
assisted  in  building  the  DSS.  This  part  or  element  of  the  decision 
process  which  is  selected  for  aiding  is  called  the  kernel. 


ROMC:  The  DSS  Conceptual  Framework 


After  the  problem  has  been  bounded  through  the  use  of 
concept  mapping  and  it  has  been  determined  which  kernel  is  to  be 
implemented,  the  question  of  designing  the  structure  of  the  DSS  still 
remains.  Sprague  and  Carlson  provide  the  framework  that  was  used 
in  this  research  which  is  known  as  ROMC  and  stands  for 
Representations,  Operations,  Memory  aids,  and  Control 
mechanisms.  This  framework  has  proven  to  be  useful  in  helping  the 
decision  maker  more  easily  define  the  decision  process  by  requiring 
the  concrete  description  of  the  tools  needed  to  support  the  decision 
process.  A  more  focused  definition  of  the  decision  process  results  in 
an  easier  identification  of  the  requirements  for  the  DSS.  As  this 
framework  clarifies  the  system's  requirements,  it  in  turn  markedly 
aids  the  development  of  system's  initial  design  while  its  continued 
use  also  aids  the  DSS's  evolution  (39:96-101;  43). 

ROMC  is  a  design  framework  that  is  independent  of  any 
particular  decision  process  or  system  that  it  has  been  used  on  in  the 
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past.  It  is  designed  to  identify  the  required  capabilities  of  a  DSS. 
The  ROMC  components  are  as  follows: 


I 


REPRESENTATIONS:  Representations  are  the  context  in  which 

the  decision  maker  interprets  output  from  the  DSS  and  invokes 
operations  of  the  system.  The  importance  of  this  part  of  the 
framework  is  reflected  in  Sprague  and  Carlson's  following 
observation: 

.  .  .  decision  makers  have  trouble  describing  a  decision-making 

process,  but  they  do  seem  to  rely  on  conceptualizations,  such 

as  pictures  or  charts,  when  making  or  explaining  a  decision  .  .  . 

(39:98) 

This  reflects  the  fact  that  any  decision-making  process  occurs  using  a 
conceptualization  of  the  information.  The  form  the  conceptualization 
may  be  mental,  a  picture,  a  map,  graph  paper,  or  any  number  of 
other  forms. 

OPERATIONS:  Operations  are  those  activities  which  support  the 
decision  process.  These  are  such  activities  as  gathering  data, 
analyzing  data,  forecasting  results  given  a  particular  set  of  stating 
data,  comparing  results  against  some  criteria  or  other  results  from  a 
different  model,  putting  the  data  or  results  into  a  presentation 
format,  preparing  reports,  and  so  on.  Changing  the  terms  of  Simon's 
paradigm,  intelligence,  design,  and  choice,  as  seen  in  the  figure 
below  and  using  it  to  help  classify  the  operations,  it  can  be  seen  how 
these  operations  support  the  decision  process  in  Figure  3  below. 

MEMORY  AIDS:  Memory  aids  are  made  up  of  both 
representations  and  operations  to  support  the  user  in  the  decision 
process  and  in  the  use  of  the  DSS.  These  aids  may  take  the  form  of: 

1)  data  files  compiled  by  the  user  as  a  result  of  a  model  the 
user  constructed  and  ran, 

2)  an  automated  check  list  that  comes  up  whenever  a  given 
process  is  initiated. 
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PROBLEM  FORMULATION 
Gather  data 
Diagnose  problem 
Validate  data 

ALTERNATIVE  GENERATION  & 

EVALUATION 

-  Gather  data 

Model  and  analyize  alternatives 

-  Sort  data 

CHOICE 

Generate  statics  on  alternatives 
Choose  among  alternative 

-  Explain  choice 

Adafed  from  Sprague  and  Carlson  p.  104 
Figure  3.  General  Decision-Making  Operations  for  Simon's  Paradigm 


3)  a  computer  notepad  to  store  notes  for  later  reference,  and 

so  on. 

CONTROL  MECHANISMS:  The  DSS  control  mechanisms  enable 
the  user  to  use  the  representations,  operations,  and  memory  aid 
with  minimal  frustration  while  proceeding  through  the  decision 
process.  As  can  be  seen  this  portion  of  the  ROMC  framework  has  a 
very  direct  link  to  the  Dialog  part  of  the  DSS's  three  major  functional 
components.  As  such,  the  control  mechanisms  are  crucial  to  the 
success  of  the  DSS  because  they  encourage  or  discourage  the  decision 
maker  to  make  direct  use  of  the  complete  DSS  in  working  through  a 
decision.  These  mechanisms  generally  take  the  form  of  the  system 
software  controls,  such  as  the  menus  or  function  keys,  or  the 
explanation/training  capabilit>  of  the  system.  I’hese  functions 
enable  the  implementation  of  the  tools  of  the  DSS,  altering  or 


combining  the  basic  tools,  etc.,  to  aid  the  user  through  the  decision 
process. 


As  indicated  in  above,  there  is  an  interrelation  among  the 
functional  components  of  the  DSS,  the  DDM,  and  the  ROMC 
framework.  An  efficient  clarification  of  this  interrelationship  is  a 
cube  developed  by  Valusek  (41;  43)  shown  in  Figure  4,  which  also 

includes  the  relation  of  Simon's  modified  paradigm. 
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Slorvboards  and  Feature  Charts 


Storyboards  and  Their  Use  in  the  Design  Process. 
Storyboards  and  the  process  of  storyboarding  is  borrowed  from  the 
animation  and  advertising  industries  where  they  are  used  to  present 
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proposed  project  scenes  or  displays.  Storyboards  for  computer  based 
systems  are  a  sequence  of  displays  depicting  the  screen 
presentations. 

These  screen  presentations  are  of  specific  functions  lor  a 
proposed  DSS  (5:3;  43).  The  depictions  support  the  adaptive  design 

process  by  enabling  an  inexpensive  preview  of  the  DSS  as  the  user 
will  see  it  and  allowing  for  quick  and  easy  modifications  to  meet 
user's  needs. 

Storyboards  are  "live"  tools.  They  are  designed  to  verify 
requirements  definitions,  help  "size"  systems  design 
specifications,  and  serve  as  compasses  to  software  engineers. 
They  are  dynamic,  subject  to  user  and  technical  review.  They 
are  also  intended  to  consume  relatively  little  of  the  systems 
design  and  development  budget,  while  protecting  the  same 
budget  from  false  starts,  inaccurate  requirements  definitions, 
and  over-eager  programmers  (5:4). 

Thus,  storyboarding  is  a  vehicle  for  requirements  generation, 
enabling  the  designer  to  easily  and  cheaply  zero  in  on  the  actual 
details  of  the  kernel  DSS  configuration  such  as  controls,  visual 
displays,  inputs,  outputs,  processes  to  be  support,  as  well  as  data 
structures  and  system  peripherals.  This  is  significant  as  these 
requirements  may  not  be  initially  evident  in  the  command  and 
control  arena  due  to  the  lack  of  a  comprehensive  command  and 
control  theory  and  the  unstructured  and/or  dynamic  environment  of 
the  decision  maker  (43;  9:7). 

The  storyboard  process  itself  is  straightforward.  After  the 
kernel  has  been  determined  using  concept  mapping,  the 
dcsigner/dcsign  team  and  the  uscr(s)  meet  to  develop  a  rough 
concept  of  the  system.  Next,  an  initial  set  of  storyboards  are 
developed  to  act  as  a  strawman.  This  set  of  storyboards  is  an  anchor 
on  which  to  elaborate,  build,  change,  and  expand.  All  members  of 
the  team,  especially  the  users,  must  review  these  storyboards  and 
revise  them  as  each  member  deems  necessary  by  actually  redoing 
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the  displays.  When  a  rough  consensus  emerges  the  storyboards  arc 
converted  into  software.  As  the  storyboards  are  to  eventually 
become  a  computer  display,  the  best  approach  is  to  construct  and 
display  the  storyboards  on  the  system  to  eventually  support  the 
working  DSS  (5:5;  43). 

Feature  Charts  and  Their  Use  m  the  Design  Process.  A 
feature  chart,  which  is  a  synthesis  of  the  ROMC  model,  is  a  symbolic 
depiction  of  the  connectivity  of  the  representations  with  which  a 
user  interacts,  the  possible  paths  from  one  to  another,  and  how  to 
navigate  to  a  desired  feature.  As  such,  feature  charts  produced  by 
the  designer/builder  serve  two  purposes.  First,  they  serve  the 

purpose  of  system  analysis  in  that  the  tasks  the  DSS  is  to  perform  are 
clearly  identified.  Second,  they  serve  as  a  very  clear 
communications  link  between  the  user  and  the  designer,  depicting 
the  designer's  impression  of  the  functions  of  the  DSS  as  necessary  to 
support  the  user's  decision  process  (37).  As  a  consequence  of  these 
purposes,  feature  charts  can  also  help  to  verify  user  needs  and 
system  requirements. 

In  addition  to  the  above,  feature  charts  also  lend  perspective 
and  dynamics  to  the  storyboarding  process.  When  used  in  concert 
with  storyboards,  feature  charts  show  the  interconnection  between 
various  displays,  thereby  giving  a  "you-are-here"  perspective 
overview  of  the  system  with  reference  to  the  storyboard  being 
looked  at  (43).  Further,  when  using  the  paper-based  storyboarding 
process  feature  charts  can  also  serve  to  give  the  user  a  better 
understanding  of  the  dynamics  and  flexibility  of  the  DSS.  This  latter 
benefit  may  not  be  significant  when  the  storyboards  are  computer 
based. 
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1  ntroduction 


Chapter  Three  discusses  the  use  of  the  DSS  methodology  to 
address  the  problem  of  aiding  the  ECCO  in  the  process  of  real-time 
retasking  of  EC  assets.  While  no  system  was  actually  fielded,  initial 
problem  identification  and  requirements  definition  using  the  DSS 
adaptive  design  p^'ocess  were  explored.  Additionally,  the  problem  of 
insuring  continued  evolution  of  the  DSS  once  the  kernel  was  fielded 
was  also  considered.  As  such,  the  initial  step  was  an  identification 
and  bounding  of  the  problem  to  be  addressed,  in  this  case  that  of 
real-time  retasking  of  Electronic  Combat  assets  in  a  conventional  war 
fighting  environment  such  as  that  of  NATO's  Central  front.  Once  the 
scope  of  the  problem  was  roughly  defined,  the  second  step  was  to 
select  that  specific  portion  of  the  problem,  the  kernel,  which  was  to 
be  implemented.  These  two  steps  are  discussed  in  the  following 
section  on  Concept  Maps  and  Kernel  Selection.  The  third  step  was  to 
determine  the  required  capabilities  of  the  kernel.  This  was 
accomplished  using  the  Storyboarding  process,  guided  by  Sprague 
and  Carlson's  Representations,  Operations,  Memory  Aids,  and 
Control  mechanisms  (ROMC)  framework.  In  the  event  that  a  system's 
capabilities  were  determined  and  the  kernel  was  fielded,  the  next 
step  would  be  to  insure  the  evolution  of  the  kernel  to  both  meet 
evolving  user  needs  and  to  set  the  stage  for  the  expansion  of  the  aid 
toward  a  complete  system  through  the  addition  of  other  kernels. 

This  is  in  many  ways  very  similar  to  the  initial  requirements 
development  and  is  discussed  in  the  section  on  Adaptive  Design  and 
Continuing  Requirements  Generation.  The  results  of  these  processes 
are  discussed  in  Chapter  Four. 
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Concept  Maps  and  k^ernel  Selection 

The  major  hurdle  to  tlie  first  steps  of  defining  and  bounding 
the  problem  is  that  the  process  of  real-time  retasking  of  liC  assets  is 
a  function  that  is  currently  executed  on  an  ad  hoc  basis.  It  is  not  a 
capability  that  is  currently  planned  for  and  exercised  as  a  normal 
function  across  all  mission  areas  as  controlled  by  the  USAF  Tactical 
Air  Control  System  (TAGS)  (11;  34).  The  activity  tliat  comes  closest 

to  practicing  some  real-time  retasking  is  in  the  mission  area  of  Close 
Air  Support  (CAS).  Here  too,  true  retasking  is  more  correctly 
described  as  an  ad  hoc  function.  The  failure  to  accomplish  retasking 
seems  to  be  due  primarily  to  the  lack  of  the  capability  to  quickly  and 
accurately  assess  the  impact  of  mission  changes,  the  lack  of  an 
ability  to  rapidly  and  securely  communicate  the  necessary 
information  to  the  forces,  the  inability  of  the  aircrews  to  digest  and 
use  the  information  if  it  were  possible  to  obtain  it,  and  the  inability 
to  reconfigure  on-board  mission  equipment/munitions  in  flight  to 
meet  the  new  threat.  In  turn,  these  shortcomings  arc  a  result  of  not 
planning  for  retasking  and  therefore  not  acquiring  this  capability. 

Phinrun^  The  task  of  real-time  retasking  is 
essentially  one  of  planning  which  has  been  forced  into  a  much 
shorter  time  frame  than  that  of  the  normal  FC  mission  planning  cycle. 
Retasking,  though,  is  still  further  removed  from  initial  planning  in 
that  the  range,  or  the  feasible  region,  of  possible  new  plans  which 
can  be  developed  is  vastly  restricted  by  the  current  environment, 
riiis  greatly  simplifies  the  generation  of  alternatives  because  many 
of  the  mission  variables  now  have  set  values  and  limits.  At  this 
point,  the  mission  factors  that  are  of  interest  are  those  factors  that 
have  changed  and  thereby  caused  the  mission  to  fall  into  the 
retasking  category.  'I'hesc  factors  now  become  the  variables  within 
the  replanning  process  such  as  an  unexpected  increase  in  the  threat 
environment  due  to  the  concentration  of  mobile  SAM/AAA  assets  in 
conjunction  with  an  enemy  offensive  thrust  ('M). 


Concept  Ma2S.  Because  real-time  BC  retasking  is  not  a  normal 
1'actical  Air  Control  Center  (TACC)  function,  there  does  not  exist  an 
expert  in  this  area.  On  the  other  hand,  there  are  experts  in  the  areas 
of  EC  mission  planning  and  the  employment  of  Close  Air  Support 
assets.  Due  to  the  real-time  nature  of  the  latter  area,  it  is  often  a 
real-time  retasking  process.  These  experts  exist  in  the  combat  plans 
and  combat  operations  sections,  respectively,  of  a  TACC.  Due  to  the 
lack  of  an  actual  expert  in  the  field  of  real-time  EC  retasking,  experts 
in  the  associated  fields  were  consulted  for  the  definition  and 
boundaries  of  the  problem,  the  functions  necessary  to  accomplish 
retasking,  and  the  necessary  capabilities  of  a  decision  aid  to  support 
the  ECCO  in  pursuing  real-time  EC  retasking.  Additionally,  various 
other  experienced  personnel  with  operational  backgrounds  in 
command  and  control,  operational  planning,  and  electronic  combat 
were  also  consulted.  From  a  composite  of  this  information  a  concept 
map  of  the  problem  domain  was  drawn  up  (See  Appendix  A). 

The  use  of  the  resulting  concept  map  allowed  the  structuring  of 
the  problem,  giving  it  scope  and  bounds,  identifying  the  major 
functions  and  activities  which  are  the  different  kernels  of  the 
process,  and  identifying  the  interconnectivity  of  the  information  and 
processes.  This  latter  area  enables  the  later  generation  of  feature 
charts  which  explicitly  show  the  inter-connectivity  of  processes  of 
the  proposed  system. 

This  composite  concept  map  showed  that  the  subject  area  of  EC 
C3I  broke  down  into  four  major  subcomponents:  Phases  of  EC  C31, 
Real-Time  Assessment  Ability,  Planning  and  Decision  Making,  and 
Execution.  Of  these  areas,  the  concept  map  confirmed  the  intuitively 
apparent  interrelationship  between  the  Planning  and  Decision 
Making  process  and  Real-Time  Assessment  Ability.  This  strong 
interconnection  points  up  the  fact  that  to  construct  a  completely 
integrated  DSS  which  supports  the  ECCO  in  replanning  requires  that 
the  DSS  eventually  support  the  ability  to  assess  the  current 
environment.  These  two  major  areas  were  broken  down  even 


further  in  the  concept  mapping  process  to  determine  the  supporting 
processes. 

The  ability  to  do  real-time  assessment  of  the  environment,  as 
determined  by  the  concept  map,  is  the  result  of  information  from 
three  major  subareas:  the  enemy  IADS  (Integrated  Air  Defense 
System)  Threat,  Blue  Assets  Status,  and  Mission  Targets.  The  ability 
to  do  planning  and  support  decision  making  was  determined  to  be  a 
function  of  the  commander's  objectives/missions,  the  principles  of 
war,  available  EC  and  support  assets,  the  generation  of  EC  support 
plan(s),  and  the  ability  to  evaluate  alternate  plans  and  choose  the 
final  plan  for  implementation.  These  eight  subareas,  as  can  be  seen 
in  Appendix  A,  in  turn  were  divided  into  finer  and  more  specific 
functions,  information  requirements,  principles,  etc.,  until  a 
thorough  understanding  was  developed  of  the  general  make  up  of 
the  decision  process  to  be  supported  and  its  bounds.  If  there  had 
existed  an  expert  from  which  this  concept  map  was  derived,  the 
next  step  would  have  been  to  continue  developing  maps  over  time 
until  these  maps  showed  a  stability.  Once  this  was  accomplish  then 
the  next  process  would  be  the  selection  of  one  of  the  subproblems, 
called  a  kernel,  as  the  starting  point  for  implementation.  As  there  is 
no  expert,  the  composite  concept  map  was  assumed  to  be  stable, 
though  possibly  not  exhaustive.  Given  that  the  map  was  stable,  the 
next  step  was  the  selection  of  the  kernel  as  the  starting  point  and 
focus  of  further  development  work. 

Out  of  the  many  elements  needed  to  support  the  ECCO  with  a 
functional  and  useful  DSS,  how  does  the  designer/builder  determine 
where  to  start?  It  has  been  suggested  that  starting  with  the  function 
that  is  the  most  time  consuming  and  mundane  is  the  place  to  begin 
(21;3-6,  3-7).  Another  starting  point  might  be  to  select  some  central 
but  well  defined  subproblem  so  as  to  engender  an  understanding  and 
confidence  in  the  process  as  well  as  providing  a  useful  clement  to 
users.  Working  with  the  user  on  a  subproblem  that  is  well 
understood  should  enable  an  easier  identification  of  the  system's 


processes  and  better  enable  the  user  to  communicate  liis/her  needs 
for  that  particular  area  of  the  system.  Once  confident  that  the 
process  is  feasible  and  the  product  of  use,  the  user  will  be  more 
willing  to  attempt  tougher  parts  of  the  system  such  as  those  parts 
that  are  less  well  understood  and  thus  harder  to  communicate  and 
implement.  It  was  the  latter  philosophy  that  guided  the  selection  of 
a  kernel  to  implement  for  the  ECCO's  DSS. 

The  ability  to  assess  the  SAM/AAA  component  of  the  IADS 
threat  is  one  such  central  and  well-defined  subarea.  Given  the 
central  importance  and  understanding  of  this  area,  it  was  selected  as 
the  starting  point,  the  kernel,  for  implementing  the  DSS.  Once  this 
decision  was  made,  the  concept  maps  were  used  to  get  a  more 
complete  understanding  of  the  general  types  of  information  needed 
to  support  this  assessment  capability.  The  next  step  was  to  present 
the  needed  information  in  such  a  manner  so  as  to  enable  the  user  to 
quickly  and  flexibly  determine  the  state  of  the  enemy  IADS,  thereby 
enabling  the  ECCO  to  make  more  rapid  and  accurate  decisions  about 
the  impact  the  IADS  will  have  on  plans  being  developed. 

Storyboards  and  feature  charts  were  used  to  determine  the  user's 
specific  requirements  of  the  system's  presentations,  functions, 
modeling  capability,  user  support  needs,  and  other  capabilities  of 
the  DSS. 


Storyboard  and  Feature  Ch  ’rts 

The  next  phase  in  developing  the  DSS  using  an  adaptive  design 
approach  was  the  development  of  storyboards,  using  Sprague  and 
Carlson's  ROMC  (Representations,  Operations,  Memory  Aids,  and 
Control  mechanism::)  approach,  to  determine  system  requirements. 
Storyboards,  as  discussed  in  Chapter  Two,  are  examples  of  the 
computer  screens,  generally  nonfunctional,  the  user  would  see  and 
use  in  the  actual  system.  'Fhese  example  screens  present  the 


representations,  operations,  memory  aids,  and  control  aids  that  the 
designer  has  developed  based  on  input  from  at  least  the  concept 
maps  and  users.  The  use  of  storyboards  allows  the  user  to  get  a 
concrete  feel  for  the  construction  and  adequacy  of  the  system  being 
proposed.  Further,  it  gives  the  user  an  anchor  or  concrete  example 
to  use  as  a  point  of  reference  from  which  to  indicate  whether  the 
proposed  system  meets  his/her  operational  needs  and  how  the 
system  must  be  changed  so  that  the  DSS  will  meet  operational  needs. 

The  adaptive  design  of  a  DSS,  or  any  system,  is  a  highly 
interactive  process  between  the  user  and  designer/builder.  As 
mentioned  earlier,  there  is  currently  no  real  expert  and/or  user  in 
the  area  of  the  real-time  retasking  of  EC  assets  though  expertise  in 
the  component  areas  does  exist  in  a  TACC.  As  such,  the  personnel  of 
the  507th  Tactical  Air  Control  Center,  Shaw  AFB,  SC,  represented 
the  closest  incarnation  to  an  EC  battle  management  expert.  Lt  Col 
Pfeiffer,  Chief  of  Combat  Operations,  and  Lt  Col  Raab,  Chief  of 
Combat  Plans,  agreed  to  act  as  the  "user"  for  this  effort  and  review 
the  system  storyboards  that  had  been  developed.  Information  on 
the  storyboards  was  exchanged  using  paper  copies  sent  through  the 
US  Postal  Service.  This  was  due  to  the  distances  involved  and  lack  of 
the  requisite  hardware  being  available  to  the  507  TACC  to  run  the 
computer-based  storyboard  presentation  developed  for  this  research. 
Only  one  exchange  was  possible  primarily  due  to  time  constraints  on 
this  effort.  Results  of  this  exchange  are  discussed  in  Chapter  Four. 

Adaptive  Design  and  Continuing  Requirements  Generation. 
The  adaptive  design  process  is  a  dynamic,  on-going  effort  aimed  at 
allowing  a  system  to  evolve  from  a  small  initial  portion  of  the  system 
to  the  ultimately  com[)lctc  system.  Along  the  way  established  parts 
of  the  system  should  also  adapt  and  evolve  to  meet  the  needs  of  the 
user  in  solving  problems  in  a  changing  environment.  'I'o  accomplish 
these  goals  there  must  be  requirements  generation  to  specifically 
identify  how  the  system  needs  to  change.  To  meet  this  need, 
storyboarding  was  used  for  requirements  generation  and  Apple 


Computer’s  HyperCard  program  was  used  to  explore  both  the 
possibility  of  an  all-encompassing  development  environment  and 
enhanced  requirements  generation  through  storyboarding.  Ihe 
latter  area  was  hypothesized  as  being  possible  if  the  user  were 
provided  with  a  presentation  method  closer  to  the  real  DSS  and  the 
user  was  supplied  with  a  system  which  allowed  the  easy 
development  of  storyboard  by  the  user,  thus  not  losing^distorting 
requirements  through  communications  problems. 

The  Use  of  HyperCard.  Currently,  most  storyboarding  is 
thought  of  as  a  paper  process  where  the  computer  screen  display  is 
rendered  on  a  paper  product.  This  static  display  is  then  presented  to 
the  user  with  an  attached  explanation  of  the  screen’s  functions. 

In  an  ideal  world,  a  user  would  be  handed  a  completed 
system,  work  with  the  system  for  a  period  of  time  long  enough  to 
identify  desired  changes,  the  system  would  be  modified  as 
requested,  and  the  system  would  then  be  returned  to  the  user  to 
begin  tlie  process  all  over  again  until  the  system  became  relatively 
stable.  The  system  would  be  stable  in  the  sense  that  it  would 
require  only  minor  changes  over  time  with  infrequent  major 
modifications.  It  would  and  can  never  be  frozen  or  become  static  as 
the  system  would  soon  not  meet  the  user’s  needs  in  a  rapidly 
changing  and  complex  environment  such  as  combat  command  and 
control. 

Functional  Display.  In  an  attempt  to  reach  this  ideal 
state,  this  research  was  conducted  using  Apple  Computer’s 
HyperCard.  HyperCard  enabled  the  placing  of  static  example  screens 
on  individual  graphics  data  fields  called  Cards.  Each  of  these  cards  is 
a  data  field  in  a  graphics  relational  data  base.  A  data  file  of  these 
cards  is  called  a  Stack.  Within  the  stack  it  is  possible  to  "link"  the 
screen  presentations  as  they  would  occur  in  an  actual  system.  I'his 
linkage  is  based  on  the  selection  of  command  menu  items  available 
on  a  particular  example  screen.  Once  an  example  menu  item  is 
selected  the  linked  field,  or  card,  is  brought  up  for  the  viewer  as  if 


the  operational  system  had  carried  out  the  function  and  modified  the 
presentation.  I'herefore,  HyperCard  was  used  to  allow  a  dynamic 
presentation,  or  functional  display,  of  the  proposed  system,  giving 
the  user  a  more  realistic  feel  for  the  functioning  of  the  proposed 
system. 

Combined  Storyboard  and  Feature  Chart.  Additionally, 
HyperCard-based  storyboarding  has  the  advantage  of  automatically 
and  simultaneously  incorporating  some  of  the  aspects  of  feature 
charting  into  the  storyboards.  While  a  HyperCard-based  system  does 
not  give  an  overview  of  the  interconnectivity  of  the  system's 
proposed  functions,  it  functionally  demonstrates  the 
interconnectivity  of  the  features.  Unfortunately,  as  mentioned 
above,  due  to  equipment  limitations  the  507  TACC  was  unable  to 
evaluate  the  prepared  HyperCard-based  storyboards  and  only 
reviewed  paper  hardcopy  printouts  of  the  example  screens. 

Software-based  Statement  of  Need  (SON).  Another 
advantage  that  the  storyboarding  process  has  to  offer  when  run 
under  a  HyperCard-based  or  similar  environment  is  the  capability  to 
generate  a  software-based  statement  of  need  (SON).  Given  a  library 
of  icons  and  screen  displays,  the  user  originated  generation  of 
storyboards  with  only  the  assistance  of  a  DSS  designer  becomes 
possible.  Once  these  storyboards  have  been  generated  and  linked  by 
the  user  as  he/she  desires,  they  can  then  be  modified  and 
reevaluated  over  several  iterations  until  the  storyboards  stabilize. 
This  stabilized  product  then  becomes  a  software-based  SON.  Further 
research  needs  to  be  done  in  this  area  as  it  holds  promise  for  easing 
and  speeding  up  the  generation  of  an  information  engineering  SON 
(41). 

A  Support  Fnviron  ment  HyperCard  offered  the 
additional  advantage  that  external  programs  can  be  called  to  support 
features  on  the  storyboards.  Short  of  actual  real-time  display 
presentations  of  the  environment,  this  capability  allows  the  user 
and/or  the  buildcr/dcsigner  of  this  environment  to  completely 


assemble  a  near  operational  system  from  scratch.  I'lie  process  of 
generating  the  displays  for  this  research  was  greatly  simplified  by 
having  an  environment  capable  of  supporting  the  entire  systems 
design/development  process.  An  enhanced  environment  capable  of 
supporting  this  process  in  an  actual  operational  environment  would 
have  enabled  the  users  to  more  rapidly  iterate  through  the  adaptive 
design  process,  test  the  operationally  effectiveness  of  the  designed 
system  as  each  part  of  the  DSS  grew  before  proceeding  too  far  on  a 
wrong  path,  and  provide  an  instant  credibility  for  the  system 
because  it  would  have  grown  up  with  the  using  unit  based  on  that 
unit’s  way  of  doing  business. 


Evaluation  Criteria 

The  establishment  of  criteria  to  evaluate  a  DSS  is  essential  to 
ensure  that  the  system  continues  to  progress  toward  the  established 
goals  which  represent  the  stated  needs  of  the  user(s).  Without  an 
evaluation  framework  and  criteria  there  is  a  tendency  for  the 
development  effort  to  not  maintain  a  continued  focus  on  the  initially 
desired  capability  of  the  system,  an  inability  to  accurately 
determine  priorities,  to  determine  the  worthwhile  problems  to  solve 
now  and  which  to  leave  until  later,  and  other  problems. 

The  criteria  developed  for  this  effort  were  originated  under  a 
framework  that  represents  the  fusion  of  work  offered  by  Sprague 
and  Carlson,  Building  Effective  Decision  Support  Systems,  and  Sweet, 
Metersky,  and  Sovereign,  Command  and  Control  Evaluation 
Workshop.  A  matrix  was  constructed  of  Sprague  and  Carlson's  four 
"F''s,  Productivity  measures.  Process  measures.  Perception 
measures.  Product  measures,  aiid  Sweet  et  al.'s  three  "M"s, 

Measures  of  Performance,  Measures  of  Effectiveness,  Measures  of 
Force  EKectiveness,  and  specific  criteria  were  developed  for  each  of 
the  twelve  resulting  cells.  This  was  done  because  the  ft)ur  P's 


provide  a  I'rainework  primarily  focusing  on  the  DSS  and  its  impact  on 
tlie  organization  while  the  three  M's  are  designed  to  ensure  the 
development  of  criteria  which  carry  a  different  perspective,  moving 
from  the  technical  aspects  of  the  DSS  to  the  environment  beyond  the 
using  organization's  forces  (41;  44). 

In  Sprague  and  Carlson's  measures; 

1)  Productivity  measures  are  used  to  evaluate  the  impact  of 
the  DSS  on  decisions. 

2)  Process  measures  are  used  to  evaluate  the  impact  of  the  DSS 
on  decision  ntaking. 

3)  Perception  measures  are  used  to  evaluate  the  impact  of  the 
DSS  on  decision  makers. 

4)  Product  measures  are  used  to  evaluate  the  technical  merit 
of  the  DSS.  (39:159) 

To  define  the  measures  put  forward  by  Sweet  et  al.: 

1)  Measures  of  Performance  (MOP)  are  evaluated  inside  the 
boundary  of  the  system  and  measure  attributes  of  system 
behavior  such  as  S/N  ratios  and  error  rates. 

2)  Measures  of  Effectiveness  (MOE)  are  evaluated  outside  the 
boundary  of  the  system  and  measure  how  the  system  performs  its 
functions  within  an  operational  environment.  Examples  of  these  are 
reaction  time,  probability  of  detection,  and  number  of  targets 
nominated. 

3)  Measures  of  Force  Effectiveness  (MOFE)  are  evaluated 
outside  the  boundary  of  the  force  being  controlled  and  measure  how 
a  C2  system  and  the  force,  of  which  it  is  a  part,  performs  mission  or 
contributes  to  the  outcome  of  the  battle  (40:2-4,  2-7). 

As  depicted  in  Figure  5,  this  yields  a  framework  for  the 
construction  of  criteria  that  cover  all  aspects  of  the  DSS  from  a  full 


range  of  perspectives.  An  exainpte  of  this  is  how  to  interpret  the 
Productivity  row: 


Matrix  cell  1  concerns  criteria  which  measure  how  internal 
system  performance  impacts  the  decisions  being  made. 

Matrix  cell  5  concerns  criteria  which  measure  how  the 
system  performs  within  a  specific  environment  impacts  the  decisions 
being  made. 

Matrix  cell  9  concerns  criteria  which  measure  how  the 
mission  performance  of  the  system/force  combination  impacts  the 
decisions  being  made. 
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Figure  5.  Evaluation  Matrix 


The  actual  criteria  which  could  be  used  are  as  follows: 

1)  Matrix  cell  1  concerns  criteria  which  measure  how  internal 
system  performance  impacts  the  decisions  being  made. 


2)  Matrix  cell  2  concerns  criteria  which  measure  how  internal 
system  performance  impacts  the  decisions  making  process. 

3)  Matrix  cell  3  concerns  criteria  which  measure  how  internal 
system  performance  impacts  the  decision  maker. 

4)  Matrix  cell  4  concerns  criteria  which  measure  internal 
system  performance. 

5)  Matrix  cell  5  concerns  criteria  which  measure  how  system 
performance  within  a  specific  environment  impacts  the  decisions 
being  made. 

6)  Matrix  cell  6  concerns  criteria  which  measure  how  system 
performance  within  a  specific  environment  impacts  the  decisions 
making  process. 

7)  Matrix  cell  7  concerns  criteria  which  measure  how  system 
performance  within  a  specific  environment  impacts  the  decision 
maker. 

8)  Matrix  cell  8  concerns  criteria  which  measure  technical 
merit  within  a  specific  environment. 

9)  Matrix  cell  9  concerns  criteria  which  measure  how  the 
mission  performance  of  the  system/force  combination  impacts  the 
decisions  being  made. 

10)  Matrix  cell  10  concerns  criteria  which  measure  how  the 
mission  performance  of  the  system/force  combination  impacts  the 
decisions  making  process. 

1 1  Matrix  cell  1 1  concerns  criteria  which  measure  how  the 
mission  performance  of  the  system/force  combination  impacts  the 
decision  maker. 


12)  Matrix  cell  12  concerns  criteria  which  measure  how 
system  technical  merits  impact  tlie  mission  performance  of  tlie 
system/force. 

riie  storyboard  presentation  of  the  LLCCO  DSS  which  was 
developed  as  a  result  of  the  application  of  these  above  tools  was  sent 
to  the  507  TACC  for  commet'.t.  The  507  'I'ACC  was  only  able  to 
evaluate  and  comment  on  the  paper  storyboard  because  they  did  not 
have  a  Macintosh  II  or  Macintosh  SE  to  run  the  HyperCard-based 
presentation.  The  results  stemming  from  their  observations  and 
work  done  by  the  author  are  presented  in  Chapter  Four  which 
follow's. 


IV.  Results,  Conclusions,  and  Recommendations 


I  ntrod  uction 


As  stated  in  Chapter  One,  the  focus  of  this  study  was  the 
generation  of  the  initial  requirements  for  a  decision  support  system. 
Chapter  Four  therefore  begins  with  a  presentation  of  the  results  of 
working  with  a  potential  user  of  the  ECCO  DSS,  the  507  TACC,  to 
develop  the  system's  initial  requirements  through  the  use  of  the 
decision  support  system  methodology  supported  by  the  adaptive 
design  approach.  This  is  followed  in  the  second  section  by  a 
discussion  of  the  current  thoughts  of  several  users  concerning  the 
use  of  a  DSS  in  the  TACC  and  where  the  biggest  payoff  may  be  for 
command  aiding.  The  final  section  covers  conclusions  and 
recommendations.  Thus,  the  major  divisions  of  this  chapter  arc: 

1)  Results  of  User  Reaction, 

2)  Is  An  EC  Retasking  DSS  Needed  by  the  TACC? 

3)  Conclusions  and  Recommendations, 

a)  Organizational  Impact:  Observations  and 
Recommendations, 

b)  ECCO  DSS:  Conclusions  and  Recommendations, 


c)  The  Storyboard  Process  and  Requirements  Generation 


Results  ^  User  Reaction 

T he  507th  Tactical  Air  Control  Center  (T ACC)  as  User.  'I’lic 
507th  Tactical  Air  Control  Center  (TACC)  acted  as  the  user  for  the 
purpose  of  iteratively  critiquing  the  ECCO  DSS  in  line  with  the 
adaptive  design  process.  There  is  currently  no  organization  that  can 
act  as  a  true  user  because  there  is  no  actual  retasking  of  EC  assets  at 
this  time.  The  closest  entity  to  a  retasking  agency  is  the  TACC 
because  it  does  both  the  planning  for  the  air  mission  for  a  large  area 
and/or  force  coverage  as  well  as  the  real-time  control  of  air  assets 
during  mission  execution.  Also,  the  TACC  does  the  active  tasking  of 
CAS  assets  during  the  battle  which  at  this  time  is  the  closest  activity 
to  true  dynamic  retasking.  The  Airborne  Command  and  Control 
Center  (ABCCC)  is  also  involved  in  the  real-time  execution  of  the  air 
battle  but  does  not,  to  the  limited  knowledge  of  the  author,  become 
as  heavily  involved  in  the  original  campaign  planning  as  the  TACC. 
Therefore,  the  TACC  was  selected  over  the  ABCCC  for  its  overall 
greater  in-depth  knowledge  of  the  full  planning  and  execution  cycle. 

507  T ACC  Com ments  on  the  ECCO  DSS.  The  personnel  of  the 
507th  Tactical  Air  Control  Center  did  not  feel  that  there  were  any 
serious  deficiencies  or  errors  in  the  proposed  ECCO  DSS.  This  appears 
to  be  due  to  the  use  of  the  concept  maps  as  a  front-end  analysis  to 
determine  the  basic  makeup  of  the  retasking  process  and  therefore 
the  required  capabilities  of  the  ECCO  DSS.  In  the  initial  phases  of  this 
study,  during  which  the  tactical  air  control  process  was  being 
researched  and  the  concept  maps  to  describe  the  process  were 
developed,  there  was  not  an  opportunity  to  interview  members  of 
the  507  TACC.  Therefore,  former  tactical  air  control  center 
personnel  currently  assigned  to  the  Tactical  Air  Warfare  Center 
('I'AWC),  IIQ  USAF,  and  HQ  ESD  were  interviewed.  The  planners  and 
controllers  of  the  507  TACC  were  in  agreement  with  tlie  developed 
concept  maps  with  one  exception  that  did  not  impact  this  study  (see 
Appendix  A,  pg.  66).  Additionally,  while  personnel  of  the  507  TACC 
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is  not  currently  viable  and  would  require  major  enhancements  to 
both  the  tactical  air  control  system  (  I'ACS)  and  to  mission  aircraft 
before  it  would  be  possible.  Chief  among  these  requirements  is  the 
availability  of  secure,  jam  resistant  contmunications  for  both  voice 
and  data.  Ihe  Jl'lDS  system  appears  to  address  this  issue  to  a  large 
degree  by  allowing  a  wide  range  of  users  to  "talk"  on  the  same 
secure,  jam  resistant  net.  Coordinciion  is  the  second  area  of  concern. 
JTIDS  also  helps  alleviate  the  coordination  problem  that  must  be 
overcome  both  in  flight,  between  supporting  and  supported  air 
forces,  and  with  ground  organizations  such  as  the  US  Army's  Air 
Defense  Artillery  (ADA)  units.  I'he  availability  of  real-time  fused 
intelligence  is  the  third  area  which  would  require  major 
enhancements  before  the  dynamic  retasking  of  EC  assets  is  a  viable 
option  to  the  commander.  The  major  enhancements  are  currently 
being  addressed  Included  with  this  information  on  enemy  systems 
is  a  requirement  for  information  on  friendly  systems.  I'his  double 
issue  supports  the  fourth  area  required  for  retasking  which  is  the 
ability  to  determine  that  there  is  in  fact  a  problem  that  must  be 
addressed  and  can  only  be  solved  through  retasking.  Upon 
determining  the  need  for  retasking,  the  next  capability  that  is 
required  is  the  generation  and  evaluation  of  alternative  plans.  The 
development  of  a  decision  support  system  attempts  to  provide  a 
vehicle  to  solve  this  problem  with  areas  for  continued  research 
outlined  in  Appendix  C.  Finally,  to  enable  the  execution  of  retasking, 
better  air  space  management  and  control  is  required,  a  means  to 
prepare  and  present  information  to  the  in-flight  crews  is  critical, 
and  the  issue  of  the  in-flight  reconfiguration  of  EC  systems  and 
ordinance  must  be  solved.  This  is  the  supporting  infrastructure  that 
must  be  present  before  the  dynamic  retasking  of  EC  assets  is 
possible. 

Syste ni  Su pportab ility  in  the  Field.  The  TACC  is  a  field  unit 
that  must  be  able  to  move  quickly  and  operate  from  austere 
locations  to  insure  its  survival  in  a  scenario  such  as  a  NAd'O-Warsaw 
Pact  war.  Fielding  the  current  generation  of  decision  aids  would 
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result  in  systems  in  the  TACC  which  are  generally  tough  to  support, 
move,  power,  and  hide.  Also,  there  is  a  concern  that  to  support  all 
the  jobs  of  the  TACC  would  result  in  a  'I'ACC  overwhelmed  with 
"black  box.es."  These  are  areas  currently  being  addressed  by  I  IQ 
TAC/DR/DO,  HQ  ESD/TCR,  RADC,  and  others. 

Human  Processing  Time  Constraints.  The  gr  atest  concern  as 
to  the  viability  of  retasking  lies  not  with  the  machn.es  but  with  the 
humans  that  control  them,  both  in  the  air  and  o'  the  ground.  'I'he 
distances  within  the  Eur  pean  theater,  west  to  ^ast,  or  the  Korean 
theater,  south  to  nor''.,  are  very  small  in  ’  ,ms  of  both  physical 
distance  and,  more  importantly,  time.  T  iS  a  real  concern  that 
retasking  will  not  De  possible  even  with  all  aspects  of  the  supporting 
infrastructure  d  scribed  above  becaus  of  the  small  time  frame 
involved.  W'diin  this  small  time  E  .ne  there  must  be  time  for  the 
ECCO  to  pmceive  a  problem  and  fiod  a  solution,  time  for  the 
commander  to  understand  and  approve  the  retasking,  lime  to  get 
the  word  out  to  the  effected  units  and  forces,  and  time  for  the  crews 
to  digest  the  information  and  act  on  it.  These  human  time 
requirements  put  the  process  of  retasking  in  doubt  to  many  and 
certainly  constrain  when  retasking  might  be  a  viable  option. 

The  Aiding  Payoff:  Greatest  For  Air  Campaign.  In  light  of 
the  potential  limitations  for  retasking  under  most  circumstances, 
how  then  can  the  air  commander  be  aided  in  taking  advantage  of 
opportunities  during  the  battle  and  shaping  his  forces  to  take  and 
maintain  the  initiative?  A  first  cut  at  the  problem  seems  to  suggest 
that  aiding  can  deliver  the  biggest  payoff  by  reducing  the  Ad'O  cycle 
from  its  current  length  of  24  to  36  hours  down  to  a  range  of  3  to  6 
hours.  Reducing  the  cycle  time  from  allotment  to  aircraft-in-the-air 
to  around  three  hours  would  still  require  the  same  infrastructure  as 
mentioned  above  but  would  give  the  air  commander  a  campaign 
force  responsive  to  his  requirements.  This  capability  has  far- 
icaching  effects.  Munitions  loading  and  between-flight  aircraft 
scrvicing/maintcnance,  "turning"  an  aircraft,  are  currently  timely 


functions  that  would  luive  to  be  made  faster  to  realize  the 
advantages  of  the  reduced  ATO  cycle,  'fhe  potential  impact  of  the 
reduced  A'l'O  cycle  also  needs  to  be  studied  in  areas  such  as  base 
facilities  support,  the  number  of  crews  required,  crew  fatigue, 
regular  aircraft  maintenance,  the  number  of  aircraft  available,  and 
the  number  of  sorties  that  could  be  theoretically  used  in  a  reduced 
cycle  versus  the  number  which  can  actually  be  supported. 


Conclusions  and  Recommendations 


'I’he  points  made  in  this  third  and  last  section  are  presented  in 
detail  in  Appendix  C  of  this  thesis.  Appendix  C  is  a  presentation  of 
the  observations,  conclusions,  and  recommendations  which  were 
made  over  the  course  of  this  study  and  which  were  noted  at  the  time 
in  the  author's  "hook  book."  A  hook  book  is  a  compilation  of 
thoughts,  observations,  conclusions,  and  so  on  gathered  over  time 
so  as  to  determine  basic  trends,  requirements,  and  findings.  It  is 
the  point  paper  of  scientific  journals.  Therefore,  it  is  suggested  that 
the  reader  refer  to  Appendix  C  for  a  more  detailed  discussion  of  the 
following  points. 

(Note  that  the  author  is  defining  some  comments  as  an 
observation  versus  a  conclusion  due  to  the  lack  of  data  from  a  field 
test  involving  the  participation  of  actual  users,  d’hose  items  tagged 
as  conclusions  are  so  labeled  because  of  the  personal  experience  of 
the  author,  as  surrogate  user,  while  developing  the  ECCO  DSS 
functional  display  using  the  HyperCard  applicalion/environment  and 
work  with  the  user  applying  the  techniques  of  storyboarding.) 

As  mentioned  earlier,  this  section  is  divided  into  three 
sections: 


1)  Organizational  Impact, 


2)  The  CCCO  DSS, 


3)  I'he  Storyboard  Process  and  Requirements  Generation. 

The  first  of  the  three  sections.  Organizational  Impact,  differs  from 
the  user's  comments  above  by  encompassing  a  larger  organizational 
perspective. 

Organizational  I  m  pact:  Observations  and  Rccoin  mend  at  ions. 
The  first  major  observation  is  actually  a  point  recommended  as 
requiring  extensive  research  in  the  form  of  operational  field  testing. 
As  a  result  of  a  detailed  examination  of  the  tactical  air  control  system 
(TAGS)  in  its  proposed  enhanced  and  modernized  future  form,  it 
does  not  appear  that  the  dynamic  retasking  of  air  assets  will  play  as 
significant  a  role  in  increasing  the  effectiveness  of  the  air 
commander  as  had  been  initially  hypothesized  at  the  beginning  of 
this  study.  As  discussed  above,  this  is  primarily  due  to  the  limited 
time  available  to  complete  the  full  decision-command  cycle  and  the 
ability  of  the  humans  to  work  within  the  typical  limited  lime  spans 
which  would  be  seen  for  retasking.  Instead,  the  author  believes  that 
reducing  the  decision-command  cycle  which  results  in  the  Al'O  would 
provide  the  air  commander  with  flexibility  that  would  show  a 
greater  overall  and  incremental  payoff  due  to  the  ability  it  would 
give  to  the  commander  to  coordinate  all  of  the  diverse  air  asset 
capabilities  against  the  evolving  threat  in  a  responsive  manner.  This 
would  allow  the  commander  to  both  react  to  an  enemy  thrust  as  well 
as  gain  the  initiative  for  himself,  resulting  in  an  air  commander 
gaining  the  momentum  and  enabling  him  to  dictate  the 
circumstances  of  the  battle. 

Secondly,  for  the  implementation  of  EC  relasking  there  is  the 
question  of  where  to  place  the  ECCO  in  those  theaters  where  there  is 
more  than  one  TACC-like  control  organization.  Due  to  the  scarcity  of 
EC  assets  it  is  only  possible  to  have  the  flexibility  to  retask  assets  if 
the  airborne  assets  of  the  entire  theater  are  considered.  Where 
relasking  requires  the  tactical  redistribution  of  assets  across 


command  boundaries,  the  question  of  authority  to  give  tlie 
appropriate  orders  elevates  tlie  issue  to  the  next  level  of  command. 
'I’his  genera'ly  means  that  a  command  level  which  normally  is  tasked 
with  the  operational/campaign  level  of  the  war  has  to  become 
involved  in  real-time  tactical  decisions,  dhus  the  question  arises 
whether  the  liCCO  should  be  assigned  at  the  theater  level  of 
command  to  advise  the  theater-wide  commander  or  at  the  tactical 
level  and  elevate  questions  of  cross  command  retasking  as  needed, 
with  the  inherent  time  delay.  This  area  requires  further  research. 

'I'hird,  as  discussed  under  User  Reaction,  to  accomplish  either 
retasking  or  reduction  of  the  over-all  theater  decision-command 
cycle,  the  TAGS  requires  extensive  modernization  of  its  equipment 
and  enhancement  of  capabilities  such  as  real-time  intelligence  input 
and  secure,  jam-resistant  communications  and  coordination. 

Fourth,  the  Air  Force  must  establish  a  system  for  the 
coordinated  management  of  decision  aids.  Personal  experience  has 
shown  that  research  is  being  done  on  projects  that  duplicate  each 
other,  as  well  as  the  work  of  this  thesis,  without  the  separate 
managing  offices  or  this  author  being  aware  of  each  other’s 
initiatives.  Parallel  research  efforts  and  redundancy  have  strengths 
and  advantages  that  often  justify  their  use.  These  strengths  and 
advantages  did  not  seem  to  be  needed  or  used  in  the  case  1  am  citing. 
Ihere  was  obviously  inefficient  use  of  limited  resources,  both  money 
and  talents,  without  any  apparent  cause.  This  can  not  be  afforded  at 
any  time  and  especially  at  a  point  in  time  which  appears  to  be 
ushering  in  an  era  of  declining  funding  for  the  foreseeable  future. 

I  he  central  coordination  of  these  efforts  will  at  least  allow  the 
sharing  of  information  from  hard  won  lessons  and  save  others  from 
"reinventing  the  wheel.” 

Fifth,  after  the  completion  of  this  thesis,  a  comparison  of  this 
research  with  that  of  a  commercial  contractor’s  work  showed  striking 
parallels  between  the  two  projects.  I'he  obvious  question  is  what 
v\as  the  difference  in  cost  to  the  Air  Force  of  having  a  single  user 
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devek)p  the  requirements  for  a  future  system  using  storyboarding  as 
opposed  to  a  contractor  team  developing  the  same  list  of 
requirements  using  any  method?  And  if  it  is  possible  to  have  using 
organizations  developing  their  own  system  requirements,  with  the 
obvious  incentive  that  implies,  while  not  degrading  their  assigned 
missions,  why  should  the  government  pay  to  have  outside 
contractors  do  this  work? 

Lastly,  for  organizational  impact,  the  implementation  of  the 
adaptive  design  will  require  that  the  Air  Force  adopt  a  flexible, 
decentralized  philosophy  toward  the  support  of  systems  developed 
under  this  concept  if  the  Air  Force  is  to  realize  the  advantages  of 
systems  responsive  to  the  local  user.  'I'his  could  be  done  by 
supporting  the  various  levels  of  the  system  at  the  lowest 
organizational  level  possible,  from  it  central,  standardized  core 
supported  at  the  Air  Force  level  to  its  specific  user  oriented  "surface" 
features  supported  at  the  wing  level. 

HCCQ  DSS:  Conclusions  and  Recom mendations. 

Conclusions.  As  no  operational  system  was  developed 
and  tested  by  a  using  organization  there  can  be  no  conclusive  finding 
as  to  the  validity,  worth,  or  operability  of  the  Electronic  Combat 
Coordination  Officer's  Decision  Support  System  or  the 
organizational/systems  concepts  put  forward  in  the  body  and 
appendix  of  this  thesis.  To  arrive  at  a  conclusion  concerning  a  ECCO 
DSS  will  require  further  research,  development,  and  operational 
field  testing  within  a  GREEN  FLAG  setting,  at  least,  by  AFIT/ENG  in 
conjunction  with  such  organizations  as  HQ  TAC/DR  and  HQ  ESD/TCR. 

Rccom  mendations.  As  mentioned  above,  a  great  deal  of 
further  research  is  required  for  the  development  of  an  operationally 
usable  and  user  accepted  ECCO  DSS. 

1 )  ECCO  DSS  Development.  It  is  recommended  that  AFIT/EN 
work  in  conjunction  within  the  currently  established  command 


aiding  slrncture  headed  by  HQ  TAC/DR  and  HQ  HSD/l'R  iti  further 
study  of  tlie  concept  of  liC  retasking  and  reduction  of  the  A'l'O  cycle, 
bield  testing  of  both  the  system  and  especially  the  operational 
doctrine  are  critical  to  the  successful  study  of  this  capability. 
Additional  agencies  that  should  also  be  included  in  the  effort  are  the 
Factical  Air  Warfare  Center  (TAWC),  the  Air  Ground  Operations 
School  (AGOS),  the  65th  Air  Division,  ATOC  Sembach,  the  507th 
Tactical  Air  Control  Center,  the  Air  Force  and  Joint  Electronic 
Warfare  Centers,  and  the  Rome  Air  Development  Center. 

Several  additional  capabilities  must  also  be  developed  for  the 
ECCO  DSS  which  have  been  suggested  via  the  storyboards  and  the 
HyperCard-based  functional  display  but  were  not  conceptually 
pursued  due  to  time  restrictions.  I'hese  include: 

2)  Deconfliction  (Frequency  and  Airspace).  The  ECCO  must  also 
have  the  ability  to  assess  the  potential  for  conflict  and  its  impact  on 
currently  scheduled  uses  of  both  the  clecliomagnctic  spectrum  and 
airspace.  Once  the  impact  is  assessed,  the  ECCO  must  have  the 
ability  to  generate  plans  which  will  minimize  the  impact.  This 
capability  would  already  exist  in  the  general  planning  capability  of 
the  DSS.  If  conflict  can  not  be  avoided  and  it  is  determined  that  the 
impact  does  not  degrade  the  other  unit’s  capabilities  too  seriously, 
the  ECCO  must  then  have  the  ability  to  communicate  a  warning  notice 
to  the  affected  units. 

3)  Models.  There  must  be  developed  and  added  to  the  DSS 
those  models  which  will  allow  the  "what  if"  planning  capability  which 
is  a  fundamental  characteristic  and  strength  of  a  DSS.  The  results  of 
the  specific  models  are  identified  via  the  storyboards  of  the  proposed 
DSS.  Examples  of  needed  iitodels  include; 

a)  EC  aircraft  models  with  1:C  and  flight  characteristics 
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modeled. 


b)  EC  effects  models  which  model  the  impact  of  EC  effects 
on  targeted  systems, 

c)  SAM  radar  and  misslc  models  which  take  into 
consideration  such  factors  as  terrain,  weather,  and  system 
reliability  to  allow  the  simulation  of  alternate  missions. 

Also  important  is  the  fact  that  to  be  truly  usable  for  joint  operations 
such  as  in  NATO  the  DSS  must  also  include  the  capability  to  plan  for 
the  employment  of  all  EC  assets  within  the  alliance  (to  include  US 
Navy  EC  assets  which  are  of  course  always  "in  support  of"). 

4)  Mission  Impact.  To  support  the  ECCO's  ability  to  evaluate 
operations  the  ECCO  must  have  a  basis  of  value  comparison.  One 
suggestion  is  to  use  the  Loss/Damage  ratio  as  a  basis  of  comparison 
between  missions  with  varying  EC  packages.  Use  of  the  Loss/Damage 
ratios  entail  comparing  the  difference  between  two  mission's  ratio  of 
their  expected  (simulated)  losses  versus  their  expected  (simulated) 
destructive  impact.  The  ECCO  must  be  able  to  determine  a 
loss/damage  ratio  for  both  the  overall  force  and  the  EC  assets  when 
proposing  a  change.  This  is  required  to  allow  the  ECCO  to  select 
among  alternative  plans.  This  will  also  enable  the  ECCO  to  determine, 
among  other  things,  the  incremental  benefits  to  a  mission  receiving 
retasked  EC  assets  and  the  impact  on  future  missions  of  losing  an  EC 
asset. 

5)  Asset  Valuation.  Inherent  in  the  last  function  mentioned 
above  is  the  capability  to  determine  the  worth  of  EC  assets  to  the 
overall  capability  of  the  air  commander.  The  difference  in 
theLoss/Damage  ratios  will  establish  the  value  of  the  EC  asset.  This 
is  a  valuation  ability  that  does  not  exist  to  the  knowledge  of  this 
author  but  which  docs  need  to  be  developed. 


Furtl'.er  iiiiproveineius  include: 

6)  d'lic  addition  of  functions  to  support  degraded  operations 
such  as  enabling  the  assignment  of  dynamic  confidence  ratings  to 
information  and  the  capturing  of  recent  battlefield  trends  to  project 
current  and  future  operations  when  input  support  systems  have 
gone  down. 

7)  Adding  powerful  memory  aids  to  provide  planning 
information  on  each  of  the  various  assets  as  well  as  the  mixed 
operations  of  different  aircraft.  Another  area  requiring  memory  aid 
support  is  the  commander's  guidance  for  overall  objectives  and  other 
similar  critical  information. 

8)  The  possible  addition  of  an  expert  system  to  guide  and 
short-cut  the  planning  process  thereby  speeding  up  the  generations 
of  plans 

The  Storyboard  Process  and  Requirements  Generation.  T'his 
research  set  out  to  develop  an  initial  set  of  requirements  for  a 
decision  support  system  to  aid  the  dynamic  retasking  of  EC  assets.  It 
was  decided  to  investigate  the  use  of  the  storyboarding  process  as  a 
vehicle  through  which  these  requirements  would  be  determined. 
Additionally,  it  was  further  decided  to  investigate  the  use  of  the 
HyperCard  application  as  an  environment  to  create  a  "functional 
display"  of  the  proposed  system  using  the  developed  storyboards. 

Due  to  time  and  user  equipment  limitations  there  was  only  one 
review  of  the  storyboards  by  the  user,  though  it  was  quite  favorable 
as  mentioned  above,  and  no  comment  on  the  HyperCard-based 
presentation  as  the  user  was  unable  to  review  it.  As  a  consequence 
of  these  limitations  a  finding  by  the  author  that  could  not  be  field 
tested  using  the  volunteer  organization  has  been  included  here 
merely  as  an  observation  because  it  is  significant  and  warrants 
further  study. 
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Conclusions 


^  1)  'I'hc  use  of  concept  mapping  allows  the  accurate  bounding  of 

the  general  subject  being  aided  as  well  as  a  selected  kernel  process. 

It  also  eases  the  identification  of  key  functiojis  requiring  the  support 

of  specific  DSS  operations. 

9 

2)  It  is  very  difficult  to  stay  within  the  identified  bounds  of  a 
kernel  due  to  the  extensive  overlapping  of  processes  within  a 
complex  system.  It  is  relatively  easy  to  avoid  this  through  constant 

#  referral  to  the  concept  map  to  assure  the  appropriateness  of  the  next 

development  step. 

3)  The  user  generation  of  requirements  through  the  process  of 
storyboarding  will  work  but  only  if  the  following  conditions  arc  met: 

A.  I’he  designer  works  with  the  user  to  develop  a  ready 
library  of  icons,  frames,  and  whatever  else  is  required  to  prevent 
the  user  from  having  to  generate  the  storyboard  building  blocks 

^  from  scratch.  I'his  a  tedious  process  which  may  well  result  in  the 

user  losing  interest  in  the  process  if  he  is  required  to  generate  it  all 
from  the  beginning.  Additionally,  prepared  building  blocks  act  as  an 
^  anchor  or  starting  point  from  which  the  user  can  evolve. 

B.  The  uscr(s)  must  be  allowed  time  to  work  on  the 
storyboards  or  functional  display  on  a  regular  (daily)  basis  to  insure 
basic  trends  and  requirements  are  captured  .  The  issue  of  gaining 
and  maintaining  the  interest  and  cooperation  of  individuals  who  are 
not  interested  in  the  effort  and  thus  do  not  put  forth  a  serious  effort 
needs  to  be  addressed.  The  issue  of  breaking  a  user  free  from  the 
pressures  of  daily  commitments  to  work  on  the  generation  of 
requirements  also  must  be  addressed. 

4)  Through  the  use  of  the  storyboarding  the  user's  information 
inputs  are  forced  to  become  concrete  and  unambiguous,  'fhe 
development  of  the  storyboards  requires  the  user  to  develop  a 
detailed  description  of  at  least  the  operational  system's  required 
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representations,  operational  functions,  control  mechanisms,  and 
possibly  the  system's  memory  aids.  The  presence  of  a  common, 
concrete  storyboard  representation  also  helps  to  minimize  user- 
designer  miscommunications  about  desired  system  requirements  (It 
is  expected  that  the  use  of  the  functional  display,  using  the 
HyperCard/  hypertext  environment,  will  further  enhance  user- 
designer  communications  and  reduce  chances  for  lasliitg 
miscommunications). 

5)  The  concept  of  a  functional  storyboard  display  is  very 
useful  in  establishing  system  requirements,  and  the  user  generation 
of  the  requirments,  because  it  provides  a  structured  framework 
which  forces  a  thorough  analysis  of  the  system's  required  features 
and  operational  interconnections/functional  relations.  Additionally, 
the  ease  of  use  of  the  HyperCard  application/environment  makes 
constructing  the  functional  display  easy,  thereby  further  opening 
the  possibility  of  the  direct  user  generation  of  requirements  as 
opposed  to  their  generation  through  the  use  of  a  designer  or  design 
team.  The  user  generation  of  requirements  is  also  supported  or 
made  possible  by  the  reasons  cited  below: 

A.  First,  the  creation  of  the  functional  display  reduces  any 
initial  conflicting  functional  demands  and  ensures  that  over  time 
there  is  no  forgetting  or  confusing  how  functions  are  interrelated  and 
points  out  to  the  user  those  linkages  which  are  contradictory. 

B.  d’he  analysis  of  a  proposed  system  is  made  easier  with  the 
construction  of  a  functional  display  because  it  is  a  shorter  step 
between  the  functional  display  and  the  operational  system  and 
therefore  easier  to  conceptualize  and  define  the  final  operational 
system. 

C.  I  he  generation  of  a  functional  display  needs  to  be  supported 
by  an  environment  which  combines  HyperCard  linking  and  support 
ca[Kibilities,  eas\  access  to  an  icon  library,  and  a  construction 
capabilit)  such  as  is  offered  in  the  MacDraw  application.  If  this  is 


not  possible,  then  it  is  important  to  tie  the  separate  applications 
together  with  an  application  such  as  Switcher  which  allows  the  easy, 
quick  transition  between  the  functional  display  environment,  the 
construction  tool,  and  the  icon  library.  This  is  to  provide  the  user 
with  the  tools  which  will  cause  the  least  interruption  in  the  thought 
process  while  working  on  the  function  display  and  therefore  a  better 
chance  of  early  development  of  staole  requirements. 

As  a  general  statement,  it  can  be  concluded  that  the  use  of 
concept  mapping  and  storyboarding  allowed  the  determination  of  a 
set  of  functional  requirements  for  an  command  and  control  decision 
aid.  There  is  no  reason  to  expect  that  this  approach  for  requirements 
generation  can  not  be  used  in  other  fields  with  equal  success.  It 
must  also  be  said,  on  the  other  hand,  that  no  actual  system  was 
developed,  fielded,  and  tested  for  both  user  acceptance  and  major 
user-required  modifications  to  establish  validity  and  stability  of  the 
generated  requirements.  A  requirement  is  stable  if  it  represents  a 
basic  requirement  of  the  system  to  meet  general  on-going  operations 
or  the  result  of  a  transient  or  scenario-specific  need.  Additionally, 
as  both  the  function  of  retasking  and  the  adaptive  design  of 
operational  systems  has  still  to  be  organizationally  adopted,  the 
requirements  derived  to  date  are  based  only  on  those  needs  as 
perceived  by  a  surrogate  user.  This  must  be  pursued  in  further 
research. 


Recommendations.  Within  the  general  subject  area  of  the 
storyboarding  process  and  requirements  generation  there  are  far 
fewer  recommendations  than  were  offered  for  the  specific  subject  of 
the  bCCO  DSS. 

l-'irst,  there  is  a  great  deal  of  work  needed  on  the  theory  and 
practical  application  of  alternative  generation.  In  Appendix  C  the 
idea  of  setting  up  a  library  of  templates  is  offered  as  a  possible 
solution  but  it  is  hoped  that  the  kind  of  solution  which  tcmplating 
represents,  brute  force,  will  not  be  the  only  solution  possible.  It  is 
hoped  that  original  generation  of  alternatives  can  be  achieved. 
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Second,  research  is  needed  into  the  possibility  of  converting 
the  desired  portions  of  a  kernel  concept  map  into  a  check  list,  or 
some  other  guide,  to  help  the  dcsigner/builder  stay  within  the 
bounds  of  the  kernel  and  not  waste  resources  working  in  peripheral 
areas. 


Finally,  research  needs  to  be  conducted  with  operational 
organizations  on  the  user  construction  of  storyboards  and  functional 
displays.  The  aim  of  these  studies  would  be  to  determine  the 
viability  of  the  user  generation  of  systems  requirements. 

Additionally,  these  studies  would  also  need  to  test  all  aspects  of 
adaptive  design  systems  development  process,  from  requirements 
generation  to  adaptive  design  modifications  to  the  evolution  of  a 
relatively  stable  system  (The  user  generation  of  requirements  will 
enable  the  concentration  of  limited  government  funds  on  the 
employment  of  contractors  for  the  productive  purpose  of  building 
systems  that  are  already  defined  as  opposed  to  the  initial  generation 
of  requirements). 
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Appendix  A:  Consolidated  Concept  Maps  for  the 
Com mand  and  Control  of 

Electronic  Combat  with  Emphasis  on  the  Real-Time 
Retasking  of  Airborne  EC  Assets 


This  appendix  contains  the  composite  concept  maps  used  for 
the  development  of  the  ECCO  DSS  storyboards.  These  concept  maps 
are  the  result  of  consolidating  the  views  of  many  different  people 
associated  with  tactical  air  command  and  control  operations.  Among 
the  people  interviewed  for  the  construction  of  these  maps  were 
personnel  of  the  507th  Tactical  Air  Control  Center,  HQ  USAF/XOORC 
(Tactical  Command  and  Control  Division),  and  the  USAF  Tactical  Air 
Warfare  Center  (TAWC). 

Pages  59  through  65  constitute  the  first  set  of  concept  maps. 
Pages  66  and  67  reflect  changes  to  the  initial  set  of  concept  maps. 
These  changes  are  the  result  of  subsequent  reviews  of  the  initial  set 
of  concept  maps  by  the  507  TACC,  personnel  of  the  TAWC,  and 
continued  assimilation  of  information  by  the  author. 

The  change  on  page  67  is  a  recommendation  designed  to 
address  an  apparent  deficiency  in  the  education  and  practice  of  both 
planners  and  commanders  alike.  According  to  members  of  the 
faculty  at  the  USAF  Air  Ground  Operations  School,  personnel  of  the 
507  TACC,  and  observations  of  this  author,  while  the  Principles  of 
War  are  terms  which  are  taught  in  Professional  Military  Education 
courses,  these  principles  do  not  exist  in  the  minds  of  planners  as  the 
essential,  living,  and  overarching  framework  to  guide  the 
development  and  execution  of  plans.  The  worth  of  these  principles 
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are  proven  throughout  the  pages  of  history  and  still  have  the 
applicability  today.  The  principles,  as  a  framework,  exist  to  serve 
as  a  guide  and  insure  that  both  commanders  and  planners  are  aware 
ot  all  aspects  of  warfare  and  fully  plan  for  war's  many  facets.  I'he 
living  existence  of  these  principles  can  only  be  fully  achieved  and 
used  if  they  are  an  integral  part  of  the  education,  training,  and  the 
memory  aids  of  support  systems  which  the  user  can  query.  The 
ability  to  prompt  such  a  memory  aid  will  help  ensure  that  all  aspects 
of  the  war  planning  and  fighting  have  been  considered  in  light  of  the 
fundamental  principles  of  war. 
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Concept  Map  of  Electronic  Combat:  Command  and  Control 
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Concept  Map  -  EC:  Command  and  Control:  Assessment 


EC;  Command  and  Control:  Assessm 
Assets  Status,  Mission  /  Target 


Concept  Map  -  EC:  Planning  and  Decision  Makin 

Commander's  Objective  /  Missions,  Available  EC 
and  Support  Assets 
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Concept  Map  -  EC:  Planning  and  Decision  Making; 
Generation  of  EC  Support  Plan(s),  Evaluate 
Plan  and  Choose  Final 


Concept  Map  -  EC:  Execution;  Final  Distribution  and 


Appendix  B:  Storyboards  for  the  Electronic  Combat  Coordination 
Officer's  (ECCO)  Decision  Support  System  (DSS) 


The  ten  storyboard  sections  which  follow  were  prepared  to 
explore  the  idea  of  generating  system  requirements  using  the 
storyboarding  process  in  support  of  the  adaptive  design  of  a  decision 
aid.  Each  section  starts  with  a  general  explanation  of  the  storyboards 
in  that  section.  Specific  information  on  the  menus  and  buttons  will 
be  found  in  the  Help  storyboards. 

The  storyboards  were  specifically  prepared  to  depict  the 
proposed  capabilities  of  a  decision  aid  to  support  the  ECCO  in  the 
single  task  of  assessing  the  impact  of  the  enemy's  IADS  on  current 
missions.  Some  initial  steps  were  also  taken  toward  depicting 
capabilities  to  support  the  generation  and  evaluation  of  alternate 
plans  to  point  out  the  need  for  a  simulation  capability.  Only  a  single 
aspect  of  the  ECCO's  overall  functions  is  intended  to  be  fully 
supported  in  these  depictions  because  this  decision  aid  is  being 
developed  under  the  adaptive  design  approach.  As  such,  only  a 
single  area  of  responsibility  was  selected  for  initial  implementation. 
Additional  functions  would  be  added  as  each  previous  area  became 
relatively  stable. 

The  storyboards  presented  are  of  only  two  basic  formats,  the 
Operations  Area  Overview  display  and  the  Help  text  display.  I'he 
Help  text  is  presented  in  the  same  menu/button  frame  as  the 
Overview  presentations  but  the  buttons  and  menus  are  non¬ 
functioning  except  the  added  RTN  (return)  button.  The  fully 
developed  ECCO  DSS  would  have  a  variety  of  formats/presentations 
in  conjunction  with  the  capabilities  required  to  support  a  wide 
variety  of  tasks.  The  presentations  for  a  fully  operational  system 


would  therefore  range  from  lists  to  spreadsheets  to  cartographic 
presentations. 

At  the  bottom  of  each  storyboard  is  an  exploded  menu  display, 
or  feature  chart,  which  is  highlighted  to  show  the  user  his  exact 
location  within  the  DSS. 

The  proposed  Operations  Area  Overview  representation  of  the 
ECCO  DSS  is  designed  to  give  the  user  a  quick  but  accurate  and 
complete  idea  of  the  context  of  the  operation(s)  which  may  be  of 
interest.  This  presentation  will  allow  the  user  to  arrive  at 
conclusions  and  decisions  based  on  a  comprehensive  and  detailed 
understanding  of  the  environment  by  allowing  the  ECCO  to  select  for 
presentation  any  level  of  information  concerning  the  present  threat 
environment,  from  a  single  site  to  the  entire  IADS  and  additional 
information.  This  is  true  whether  monitoring  actual  missions  or 
developing  a  new  plan  using  the  aid’s  simulation  capability. 

Examples  of  some  of  the  specific  types  of  presentations  which  can  be 
displayed  are  flight  paths,  orbits,  the  location  of  a  theat,  the  type  of 
threat,  threat  ranges,  the  effect  that  altitude  variation  has  on  the 
threat  characteristics,  individual  or  aggregated  forces,  as  well  as  a 
number  of  other  things.  An  example  of  the  ability  this 
representation  gives  the  ECCO  is  using  the  altitude  variation  control 
on  the  SUPRT/AIR  CNTL  -  ALL  display  to  search  for  threat-free 
ingress  routes  through  the  enemy  IADS  which  developed  because  of 
terrain  masking. 

The  operations  available  to  the  user  of  the  ECCO  DSS  support  all 
phases  of  the  decision  cycle.  The  presentation  of  information  on  both 
enemy  and  friendly  forces  enables  the  ECCO  to  anticipate  potential 
problem  areas.  This  capability  is  backed  up  by  automatic  features 
which  alert  the  user  in  the  case  that  there  are  deviations  from  the 
plan  which  exceed  default  or  user-specified  error  margins.  The 
presence  of  aircraft  and  threat  models  allow  the  construction, 
simulation,  and  rough  visual  evaluation  of  alternative  plans.  E'uturc 
expansions  ol  the  DSS  under  the  adaptive  design  process  will  allow 


the  more  detailed  analysis  of  the  alternative  plans  by  using  such 
criteria  as  loss/destruction  ratio.  A  further  expansion  of  the  system 
will  allow  the  automatic  generation  of  flight/mission  information  for 
the  retasked  and  supported  aircraft  to  support  the  command  and 
execution  of  the  selected  retasking  plan. 

The  ECCO  DSS  has  a  myriad  of  memory  aids  for  use  both  with 
the  initial  operating  capacity  and  later  expansions.  These  include 
such  aids  as  friendly  organizational  ground  force  boundaries, 
friendly  ADA  positioning  and  status,  state  vectors  with  varying 
information  for  both  surface  and  airborne  forces,  extensive  data 
bases  to  support  models  or  be  scanned  by  the  user,  system  default 
values  for  the  various  presentations  or  for  the  configuration  of  the 
simulation  models,  a  HOOK  BOOK  workspace  for  recording  thoughts 
or  other  information  which  automatically  copies  the  display  the  user 
was  on  when  the  Hook  Book  was  requested  so  as  to  preserve  the 
context  of  the  user's  thought,  and  many  other  aids. 

The  number  of  control  mechanism  available  is  extensive.  A 
thorough  reading  of  the  HELP  file  will  show  the  user  the  many 
different  ways  in  which  to  use  the  representations,  operations,  and 
memory  aids  in  the  process  of  arriving  at  a  final  decision  or  in 
generating  and  evaluating  flight  missions. 
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Introduction 


The  INTRODUCTION  storyboard  welcomes  the  user  to  the 
functional  display  of  the  LCCO  DSS  storyboards  and  briefly  explains 
the  purpose  of  the  presentation. 

The  HyperCard  page  is  a  scrolling  text  field  which  the  user  can 
read.  There  are  no  operations  or  memory  aids  associated  with  this 
storyboard.  The  control  mechanisms  on  this  storyboard  are  the 
HOUSE  and  BEGIN  buttons  which  respectively  allow  the  user  to  move 
to  the  HyperCard  HOME  card  or  start  the  ECCO  DSS  presentation. 
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UJELCOME  TO  THE  ELECTRONIC  COMBRT  COORDINATION  OFFICER'S  ^ 
(ECCO)  DECISION  SUPPORT  SVSTEM  (DSS)  FOR  THE  DVNAMIC  RETASKING 
OF  ELECTRONIC  COMBRT  (EC)  ASSETS 

by  MRJ  CHARLES  D.  FLETCHER  — 

INTRODUCTION 

The  accompanying  HyperCard  stack  is  an  automated  presentation 
of  the  storyboards  for  the  proposed  Electronic  Combat  Coordination 
Officer's  (ECCO)  Decision  Support  System  (DSS).  tlihile  it  is  a  factional 
display,  there  is  no  softmare,  such  as  a  model  or  data  base/DBMS, 

"behind "  the  presentations  to  make  the  system  operational.  Similarly, 
there  are  no  actiue  data  or  intelligence  inputs  to  the  system  to  make 
the  battlefield  presentations  operable.  This  is  strictly  a  functional 
display  designed  to  giue  the  proposed  user  an  idea  of  mhat  the  system 
mould  look  and  feel  like.  As  such,  these  storyboards  act  as  a  stramman 
for  the  user  to  use  as  a  starting  point,  or  anchor,  from  mhich  to  tell 
the  designer  mhat  are  the  requirements  for  this  type  of  system. 


NOTES  ON  THE  PRESENTATIONS 
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for  the  user  to  use  as  a  starting  point,  or  anchor,  from  mhich  to  tell 
the  designer  mhot  are  the  requirements  for  this  type  of  system. 

NOTES  ON  THE  PRESENTRTIONS 


The  displays  mhich  are  seen  in  this  model  are  representatiue  of 
mhat  the  full-up  system  mould  haue.  Llihile  the  full-up  system  mould 
haue  the  ability  to  support  the  presentation  of  any  combination  of 
information  requested,  such  as  IflDS  -  SRM,  MOBILE  and  RTTRCK  GROUP  - 
TARGETS  (RLE),  this  presentation  of  the  proposed  system  does  not  shorn 
that  capabil.'y  due  to  the  thousands  of  possible  combinations,  the 
requirement  that  each  presentation  be  custom  made,  and  the  time 
constraint  of  this  program.  Therefore,  the  displays  shomn  here  are 
generally  confined  to  certain  combinations  under  a  single  menu  heading 
and  generally  enclude  combinations  of  information  mhich  are  the  result 
of  requests  made  under  different  menu  headings. 

KKK  -  Those  menu  headings  or  menu  items  that  are  nonfunctional 
are  marked  by  an  "khk"  before  or  after  the  Item. 


The  start  up,  or  default,  screen  mill  shorn  the  FEBR  (Formard  Edge 
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KHH  -  Those  menu  headings  or  menu  items  that  are  nonfunctii  ^ 
are  marked  by  an  "hkk"  before  or  after  the  item. 

BBOIB 

The  start  up,  or  default,  screen  luili  shorn  the  FEBR  (Formard  Edge 
of  the  Battle  Brea),  the  mobile  SBM  systems,  and  the  rings  of  those 
SBM  systems  luhich  define  the  maKimum  range  of  the  associated  missle. 

Rdditionally,  only  one  specific  function  of  the  proposed  system  is 
being  presented  for  comment  because  this  system  is  being  deueloped 
under  the  adaptiue  design  process.  The  function,  or  kernel,  of  the  DSS 
being  implemented  here  is  that  mhich  assists  the  ECCO  in  assessing  both 
the  impact  of  changes  in  the  enemy's  IRPS  on  the  missions  in  flight  and 
eualuating  the  desirability  of  retasking  auailable  assets  to  take 
aduantage  of  those  changes.  LPhile  it  is  realized  that  other  portions  of 
the  proposed  system  are  euentually  needed  to  fully  support  all  aspects 
of  the  ECCO's  duties,  under  the  adaptiue  design  process  the  additional 
functional  areas  are  intended  to  be  added  in  the  future  as  continued 
points  of  groLuth  for  the  system. 
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Ground  Forces 


The  GROUND  FORCES  menu  control  enables  the  user  to  request 
the  presentation  of  the  selectable  combinations  of  friendly  and 
enemy  ground  forces.  The  organizational  level  of  the  units  is  either 
user  selectable  or  a  function  of  the  size  of  the  area  being  viewed. 
The  latter  is  the  default  selection  procedure.  See  the  HELP  file  for  a 
thorough  explanation  of  the  representations,  operations,  memory 
aids,  and  control  mechanism  available  to  the  user  on  these  pages. 
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IADS  (Integrated  Air  Defense  Svstem) 


The  IADS  menu  control  enables  the  user  to  request  various 
components  and  combinations  of  components  of  the  enemy 
integrated  air  defense  system.  This  allows  the  differentiation 
between  air  and  ground  threats,  fixed  or  mobile  ground  threats,  and 
SAM  or  AAA  systems.  It  also  allow  the  user  to  display  the  ranges  of 
the  threat  systems'  radars  and/or  weapons  ranges  after  they  have 
been  affected  by  terrain,  jamming,  weather,  or  other  factors. 
Additionally,  the  IADS  menu  allows  the  presentation  of  those  enemy 
radar  systems  which  are  used  to  supply  the  threat  system  with 
acquisition  information.  The  page  can  also  show  the  C2  connectivity 
between  the  units  if  the  IADS.  The  presentation  will  give  a  projected 
degradation  of  these  connections  based  on  simulation  models  which 
use  the  position  of  the  sites,  terrain,  weather,  type  countermeasure 
being  used,  the  location  of  the  countermeasure  being  used,  and 
mode  of  the  enemy  radar  *0  name  the  major  factors.  See  the  HELP 
file  for  a  thorough  explanation  of  the  representations,  operations, 
memory  aids,  and  control  mechanism  available  to  the  user  on  these 
pages. 
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Attack  Groui 


The  ATTACK  GROUP  menu  control  enables  the  user  to  view 
various  combinations  of  information  concerning  both  the  friendly  air 
forces  and  the  tasked  targets.  This  covers  direct  attack  forces, 
support  forces  such  as  the  EC  and  air  refueling  forces,  targets 
selected  to  be  physically  destroyed  (hard  kill),  and  targets  selected 
for  neutralization  through  other  than  physical  destruction  such  as 
through  the  use  of  ECM  (electronic  countermeasures).  See  the  HELP 
file  for  a  thorough  explanation  of  the  representations,  operations, 
memory  aids,  and  control  mechanism  available  to  the  user  on  these 
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)ort  /  Air  Control 


The  SUPPORT  /  AIR  CONTROL  menu  control  enables  the  user  to 
access  information  on  the  various  mechanisms  required  to  support 
air  operations,  such  as  bases,  to  access  mission  guidance 
information,  such  as  ROEs  (rules  of  engagement),  and  to  access 
information  on  air  space  control  issues.  The  user  is  able  to  access 
information  for  air  space  control  issues  over  both  varying  altitude 
and  time.  See  the  HELP  file  for  a  thorough  explanation  of  the 
representations,  operations,  memory  aids,  and  control  mechanism 
available  to  the  user  on  these  pages. 
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The  PAGE  menu  control  enables  the  user  to  move  to  other  page 
formats  which  are  basically  different  so  as  to  support  other  aspects 
of  the  planning-evaluation-decision  steps.  These  other  pages  support 
attrition-damage  analysis,  frequency  management,  and  air  space 
management.  The  capability  to  directly  support  the  generation  of 
new  displays,  a  DESIGN  page,  to  indicated  user  desired  changes  and 
enhancements  is  to  be  added  later.  See  the  HELP  file  for  a  thorough 
explanation  of  the  representations,  operations,  memory  aids,  and 
control  mechanism  available  to  the  user  on  these  pages. 
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The  EDIT  menu  control  enables  the  selection  of  display 
information  and  the  user's  ability  to  construct,  manipulate,  and 
terminate  simulations.  See  the  HELP  file  for  a  thorough  explanation 
of  the  representations,  operations,  memory  aids,  and  control 
mechanism  available  to  the  user  on  these  pages. 
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Note  Book 


The  NOTE  BOOK  menu  control  enables  the  access  of  either  the 
Note  Book  or  the  Hook  Book  as  well  as  the  control  of  these 
documents.  See  the  HELP  file  for  a  thorough  explanation  of  the 
representations,  operations,  memory  aids,  and  control  mechanism 
available  to  the  user  on  these  pages. 
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The  Simulation  Column 


The  SIMULATION  COLUMN  is  the  vertical  column  of  individual 
buttons  on  the  left  side  of  the  screen.  These  buttons  enable  the  user 
to  set  up  and  run  a  simulation  using  any  combination  of  the  available 
aircraft  models.  The  one  exception  is  the  use  of  the  ZOOM  button. 

The  ZOOM  button  allows  the  user  to  define  an  area  of  interest  which 
is  to  be  expanded  to  fill  the  display.  The  expansion  area  will  fill  the 
screen  but  the  resolution  of  the  terrain  is  tied  to  preset  DMA 
(Defense  Mapping  Agency)  map  presentation  sizes.  See  the  HELP  file 
for  a  thorough  explanation  of  the  representations,  operations, 
memory  aids,  and  control  mechanism  available  to  the  user  on  these 
pages. 
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The  HELP  menu  provides  the  user  with  a  combined  DSS  tutorial 
and  individual  item  Help  file.  Within  each  item  is  an  explanation  of 
the  representations,  operations,  memory  aids,  and  control 
mechanism  available  to  the  user.  The  Help  file  is  structured  in 
generally  the  same  order  as  on  the  listed  subject  contents  pages 
which  begin  on  the  next  page. 
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-  RLE 

Shoms  all  BLUE  air  forces  associated  uiith  current  attack,  or 
strike,  forces 

-  ALL  EC 

Shou/s  only  the  EC  air  assets  currently  airborne 


RTN 


KC- 
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Other 
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-  SELECT 

Allouis  the  user  to  prescribe  those  air  assets  to  be  presented 
through  use  of  uarious  designations;  attack  force  designation,  cell 
designation,  aircraft  call  sign,  EC  cell,  etc. 


EF-1 1 1 

Allows  the  display  of  only  EF-1 1 1  assets  currently  airborne 
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-  F-4G  RT/ 

Riloiiis  the  display  of  only  F-4G  assets  currently  airborne  - 

-  EC-IiO 

Rlloius  the  display  of  only  EC-130  assets  currently  airborne 

-  EHPEND  (EHPENDHBLES) 

RIIolus  the  discrete  selection  and  display  of  eKpendable  assets 
currently  airborne.  The  selection  capability  is  initially  by  weapon 
system  and  then  by  any  combination  of  the  following:  mission 
number,  target  number,  target  priority,  actiue  operation  time,  or 
by  displaying  all  of  the  selected  system. 

-  TGTS  (RLE) 

Allows  the  discrete  selection  and  display  of  all  targets  assigned 
to  those  assets  currently  airborne.  Targets  displayed  will  be  both 
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RTN 


hard  kill  and  soft  kill  types.  (Hard  kill  targets  are  those  targets  i - 

to  be  physically  destroyed.  Soft  kill  targets  are  those  targets 
that  EC/Other  capabilities  are  tasked  against.) 

Selection  of  targets  to  be  displayed  can  be  by  displaying  all 
targets,  by  target  priority,  by  type  of  target  kill,  by  target  number, 
or  any  combination  of  the  aboue. 


EXPD 
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piher 
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path 


-  TGTS  (HARD  KILL) 

fliloujs  the  selection  and  display  of  targets  luhich  are  to  be 
physically  destroyed.  Selection  can  be  for  all  targets  or  by  any 
combination  of  the  following:  by  target  priority,  by  target  number, 
by  uieapon  system  tasked  against  it/them,  or  time  on  target  (TOT). 
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-  TGTS  (SOFT  KILL) 

nilouis  the  selection  and  display  of  targets  luhich  ore  to  be 
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-HHACK  GROUP  MENU:  TGTS  (SOFT  KILL)  cont.  RTN 

operationally  degraded.  Selection  can  be  for  all  targets  or  by  - 

any  combination  of  the  following:  by  target  priority,  by  target 
number,  by  weapon  system  tasked  against  it/them,  or  time  of 
effect  on  target  (TOT). 

BUnONS 

-  ACT  (ACTIUITV)  BUHON 

The  ACTIUITV  button  is  the  last  button  of  the  simulation  column. 
(The  simulation  column  is  the  uertical  column  of  buttons  on  the  left 
side  of  the  display.)  The  actiuity  button  allows  the  user  to  designate 
that  portion  of  the  flight  path  on  which  the  simulated  asset  will  be 
actiue  for  its  mission. 

ERAMPLE:  First,  an  orbit  is  requested,  using  the  Orbit  simulation 
button,  and  placed  at  the  desired  location  on  the  display  screen  by 
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-BUnONS:  ACT  (ACTIUITV)  BUnON  cont.  RTf 

the  ECCO.  This  automatically  places  the  DS$  in  the  simulation  1.. 
mode,  amaiting  a  second  actiuation  of  the  SIM  button  to  initiate  the 
simulation  run  during  ujhich  statistics  such  as  attrition  are 
automatically  compiled.  (The  SIM  button  mill  blink  during  the  period 
the  DSS  remains  in  the  simulation  mode.)  Second,  an  aircraft  model 
is  selected,  again  using  the  desired  simulation  button.  This  model 
aircraft  is  confiured  by  the  system  user  and  then  position  ouer  the 
orbit.  The  system  matches  the  orbit  and  the  aircraft,  selecting  an 
auerage  operational  airspeed  and  an  altitude  equal  to  the  display's 
selected  presentation  altitude  or  as  designated  by  the  user  during 
the  aircraft  model  configuration. 

Finally,  the  user  selects  the  ACT  button  and  mooes  the  pointer  to 
the  position  on  the  flight  path  where  the  aircraft  is  to  initiate 
operations.  At  this  point  the  system  user  holds  the  mouse  button 
down  and  drags  the  pointer  ouer  that  portion  of  the  flight  path  or 
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-BUnONS:  ACT  (flCTIUlTV)  BUHON  cont. 
orbit  where  the  system  is  to  simulate  the  selected  EC  asset 
being  actiue.  This  acitue  area  can  be  broken  up  by  releasing  the 
button,  mouing  to  the  new  location  and  depressing  the  mouse 
button  again,  dictating  another  area  of  actiuity. 

Rctiuity  of  a  selected  simulated  aircraft  can  also  be  determined 
during  the  aircraft's  mission  configuration  which  occurs  immediately 
after  aircraft  selection. 

-  flIRCRflFT,  SIMULRTED 

—  EC-130  BUnON 

The  EC-130  button  allows  the  selection  and  placement  by  the  user 
of  a  model  which  simulates  the  actiuities  and  effects  of  an  EC-130. 
Upon  selecting  the  button,  the  DSS  automatically  drops  into  the 
simulation  mode,  freezing  the  display  with  the  last  presented  real- 
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—  EF-111  BUnON  RTN 

The  EF-1 1 1  button  allou/s  the  selection  and  placement  by  the  - 

user  of  a  model  which  simulates  the  actiuities  and  affects  of  an  EF- 
111.  Upon  selecting  the  button,  the  DSS  automatically  drops  into 
simulation  mode,  freezing  the  display  with  the  last  presented  real- 
world  information,  and  awaits  the  user's  command  to  either  initiate 
simulation,  by  selecting  the  SIM  button,  or  return  to  the  real-world 
mode  by  selecting  the  REAL  button.  (The  SIM  button  will  blink  during 
the  period  the  DSS  remains  in  the  simulation  mode.)  RIso  upon 
selection  of  the  aircraft  button,  the  aircraft's  configuration  control 
panel  is  automatically  presented  to  the  user.  Once  the  model's 
mission/systems  configuration  is  complete  and  the  CONTINUE  button 
selected,  a  model  representation  is  presented  on  the  screen  for 
placement  by  the  operator.  R  FLIGHT  PATH  OR  ORBIT  MUST  FIRST  BE 
POSITIONED  ON  THE  SCREEN  BEFORE  THE  HIRCRRFT  IS  PLACED  OR  THE 
SIMULRTED  fllRCRRFT  IIJILL  "CnRSII."  (Selection  and  placement  of  a 
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— BUnONS:  fllRCRflFT,  SIMULATED:  EF-lll  BUHON  cont.  RTh 

flight  path/orbit  is  done  using  the  FLT  PATH  or  ORBIT  simulation  - 

buttons.)  The  simulation  is  initiated  by  selecting  the  SIM  button. 

—  EHPD  (EHPENDRBLES)  BUnON 

The  EHPD  button  allows  the  selection  and  placement  by  the  user 
of  a  model  which  simulates  the  actiuities  and  affects  of  any  of  the 
operational  eKpendable  EC  assets  currently  modelled  and  auailable 
on  this  system.  Upon  selecting  the  button,  the  DSS  automatically 
drops  into  the  simulation  mode,  free2ing  the  display  with  the  last 
presented  real-world  information,  and  awaits  the  user's  command 
to  either  initiate  simulation,  by  selecting  the  SIM  button,  or  return 
to  the  real-world  mode  by  selecting  the  REAL  button.  (The  SIM 
button  will  blink  during  the  period  the  DSS  remains  in  the  simulation 
mode.)  Also  upon  selecting  the  eupendables  button,  the  user  is 
presented  with  a  list  of  the  auailable  simulated  eKpendable  EC 
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— BUnONS:  flIRCRHFT,  SIMULATED:  F-4G  (UJILD  lUEflSEL)  cont.  j  RTN 
buttons.)  The  simulation  is  initiated  by  selecting  the  SIM  button! _ 


—  KC-135  BUnON 

The  KC-135  button  allouis  the  selection  and  placement  by  the 
user  of  a  model  uihich  simulates  the  actiuities  and  affects  of  an  KC- 
135.  Upon  selecting  the  button,  the  DSS  automatically  drops  into 
simulation  mode,  freezing  the  display  mith  the  last  presented  real- 
uiorld  information,  and  aiuaits  the  user's  command  to  either  initiate 
simulation,  by  selecting  the  SIM  button,  or  return  to  the  real-ujorld 
mode  by  selecting  the  REAL  button.  (The  SIM  button  mill  blink  during 
the  period  the  DSS  remains  in  the  simulation  mode.)  Also  upon 
selection  of  the  aircraft  button,  the  aircraft's  configuration  control 
panel  is  automatically  presented  to  the  user.  Once  the  model's 
mission/systems  configuration  is  complete  and  the  CONTINUE  button 
selected,  a  model  representation  is  presented  on  the  screen  for 
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--BUnONS:  filRCRflFT,  SIMULATED:  KC-135  BUnON  cont.  rTN 

placement  by  the  operator.  A  FLIGHT  PATH  OR  ORBIT  MUST  FIRST  1. 

BE  POSITIONED  ON  THE  SCREEN  BEFORE  THE  AIRCRRFT  IS  PLACED  OR  THE 
SIMULATED  AIRCRAFT  IDILL  "CRASH."  (Selection  and  placement  of 
a  flight  path/orbit  is  done  using  the  FLT  PATH  or  ORBIT  simulation 
buttons.)  The  simulation  is  initiated  by  selecting  the  SIM  button. 

--  OTHER  BUnON 

The  OTHER  button  alloms  the  selection  and  placement  by  the  user 
of  a  model  luhich  simulates  the  actiuities  and  affects  of  selected 
other  air  assets  currently  modelled  and  auailable  on  this  system. 
Upon  selecting  the  button,  the  DSS  automatically  drops  into  the 
simulation  mode,  freezing  the  display  mith  the  lost  presented  reol- 
morld  information,  and  amaits  the  user's  command  to  either  initiate 
simulation,  by  selecting  the  SIM  button,  or  return  to  the  real-morld 
mode  by  selecting  the  RERL  button.  (The  SIM  button  mill  blink  during 
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— BUnONS:  HIRCRflFT,  SIMULATED:  OTHER  BUHON  cont.  RTN 

the  period  the  DSS  remains  in  the  simulation  mode.)  Also  upon  - 

selecting  the  enpendables  button,  the  user  is  presented  with  a  list 
of  the  auailable  simulated  aircraft  from  uuhich  any  combination  of 
these  systems  can  be  selected  for  use.  Once  the  systems  ore 
selected  and  the  CONTINUE  button  is  pressed,  the  DSS  mill  present 
the  operator  uiith  the  mission  configuration  options  for  each 
selected  aircraft.  After  completing  the  model's  mission/systems 
configuration  and  the  CONTINUE  button  selected,  a  model 
representation  is  presented  on  the  screen  for  placement  by  the 
operator.  A  FLIGHT  PATH  OR  ORBIT  MUST  FIRST  BE  POSITIONED  ON  THE 
SCREEN  BEFORE  THE  AIRCRAFT  IS  PLACED  OR  THE  SIMULATED  AIRCRAFT 
IDILL  "CRASH.''  (Selection  and  placement  of  a  flight  path/orbit  is 
done  using  the  FLT  PATH  or  ORBIT  simulation  buttons.)  The  simulation 
is  initiated  by  selecting  the  SIM  button. 
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-  CLR  (CLEAR)  BUHON 

Selection  of  the  CLEAR  button  resets  the  display  to  its  turn¬ 
on/default  setting.  The  turn-on/defoult  setting  shoius  only  the  FEBR, 
mobile  SRMs,  and  each  SAM's  maKimum  lethal  missile  range. 

-  FLT  (FLIGHT)  PATH  BUHON 

Selection  of  the  FLT  PATH  button  allou/s  the  operator  to  designate 
where  a  model  aircraft  will  fly  during  a  simulation.  Upon  selecting 
the  button,  the  OSS  automatically  drops  into  the  simulation  mode, 
freezing  the  display  with  the  last  presented  real-world  information, 
and  awaits  the  user's  command  to  either  initiate  simulation,  by 
selecting  the  SIM  button,  or  return  to  the  real-world  mode  by 
selecting  the  REAL  button.  (The  SIM  button  will  blink  during  the 
period  the  DSS  remains  in  the  simulation  mode.)  To  define  a  flight 
path,  the  operator  moues  the  cursor/pointer  to  the  desired  start 
point  of  the  model  aircraft's  route  at  the  start  of  the  simulation 
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-BUnONS:  FLT  (FLIGHT)  PATH  BUnON  cont. 
and  glues  the  mouse  a  single  click.  This  luill  anchor  the  path  to 
that  point.  The  operator  then  moues  the  pointer  along  the  desired 
flight  path  to  the  nent  turn  point.  Rs  this  is  being  done,  the  path  is 
laid  out  os  a  straight  line  from  the  anchor  point  to  the  pointer  tip. 

Rt  the  desired  turn  point,  the  operator  glues  the  mouse  another 
click  ujhich  anchors  the  flight  path  as  a  straight  line  betuieen  this 
point  and  the  last  instance  the  flight  path  mas  anchored.  Rt  the  end 
of  the  desired  flight  path  the  operator  double  clicks  the  mouse  on 
the  desired  end  point  and  the  system  then  anchors  the  line  of  flight 
at  that  point  and  terminates  the  route.  R  FLIGHT  PATH  OR  ORBIT  MUST 
FIRST  BE  POSITIONED  ON  THE  SCREEN  BEFORE  THE  SIMULHTED  fllRCRRFT  IS 
PLACED  OR  THE  fllRCRRFT  lUILL  "CRRSH." 

-  ORBIT  BUnON 

Selection  of  the  ORBIT  button  alloms  the  operator  to  designate 
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-BUnONS:  ORBIT  BUTTON  cont.  rTN 

luhere  a  model  aircraft  uiill  fly  an  orbit  during  a  simulation.  - 

Upon  selecting  the  button,  the  DSS  automaticaily  drops  into  the 
simulation  mode,  freezing  the  display  mith  the  last  presented  real- 
Luorld  information,  and  aujaits  the  user's  command  to  either  initiate 
simulation,  by  selecting  the  SIM  button,  or  return  to  the  real-morld 
mode  by  selecting  the  RERL  button.  (The  SiM  button  luiil  blink  during 
the  period  the  DSS  remains  in  the  simulation  mode.)  To  define  the 
orbit  area,  the  operator  mooes  the  cursor/pointer  to  the  desired 
point  of  the  model  aircraft's  orbit  at  the  start  of  the  simulation  and 
giues  the  mouse  a  double  click.  This  mill  anchor  the  center  of  the 
orbit  to  that  point.  R  FLIGHT  PRTH  OR  ORBIT  MUST  FIRST  BE  POSITIONED 
ON  THE  SCREEN  BEFORE  THE  SIMULATED  RIRCRRFT  IS  PLACED  OR  THE 
RIRCRHFT  UJILL  "CRHSH. " 
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-  REAL  (REflL-UJORLD)  BUHON  RTN 

The  REAL  button  performs  tuio  fuctions.  The  first  is  to  inform - 

the  user  of  the  system  that  the  DSS  is  operating  in  a  real-morld 
mode,  using  actual  operational  inputs  to  generate  the  presentations 
and  information  being  displayed.  It  does  this  by  being  highlighted 
uihile  the  SIM  button  is  simultaneously  subdued. 

The  second  function  is  to  enable  to  DSS  operator  to  instantly 
terminate  a  simulation  by  using  the  pointer/cursor,  commanded  by 
a  mouse,  to  click  on  the  RERL  button.  IDhen  the  RERL  button  is 
actiuated  in  this  manner  it  highlights  itself,  all  simulation  is 
terminated  (the  simulation  data  and  statistics  are  automatically 
stored  for  later  use),  and  the  display  is  updated  to  reflect  current 
real-ujorld  information. 

-  SIM  (SIMULATION)  BUHON 

The  SIM  button  performs  tmo  functions.  The  first  is  to  inform  the 

r<5i2ir3n 


Til 

IS  IS  n  MEHSIIRE  IIF  THE  SMALL  MAC  IIVPEACHRO  AREA  BELAAI. 

■CLR 

GROUND 

FORCES 

IADS 

RTTRCK 

GROUP 

SUPRT/ 
AIR  CNTL 

PAGE 

EDIT 

NT 

BK 

HELP  ■ 

iooro 

J 


EF- 
1  )  1 


F-40 


EC- 

130 


EXPD 


KC- 

135 


pth«r 


Orbit 


Fiy 

PATH 


RTN 


-BUnONS:  SIM  (SIMULATION)  BUHON  cont. 
obseruer  that  the  system  is  operating  in  a  simulation  mode  and 
that  the  displayed  information  is  being  computer  originated  (though 
the  general  background  may  haue  been  the  last  real-ujorld 
information  receiued  prior  to  begining  the  simuoltion  run).  It 
indicates  this  uihen  the  SIM  button  is  highlighted  and  the  REAL 
button  is  subdued. 

The  second  function  is  to  place  the  system  into  a  simulation  mode 
and  then  initiate  a  simulation  run  after  the  EC  asset  models  haue 
been  placed  and  readied  for  the  run.  To  piace  the  DSS  into  a 
simulation  mode  requires  that  the  SIM  button  be  clicked  on  by  the 
cursor/pointer  of  the  mouse  or  that  one  of  the  simulation  models  be 
requested  as  euplained  under  each  of  the  models.  To  initiate  a 
simulation  run  requires  that  the  SIM  button  be  clicked  on  by  the 
cursor  regardless  of  horn  the  DSS  uias  placed  in  the  simulation  mode. 
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-  ZOOM  BUnON  RTN 

The  ZOOM  button  alloius  the  operator  to  discretely  select  and - 

enlarge  subportions  of  the  area  being  uieived  as  u^ell  os  returning  to 
the  original  large-area  oueruieiu.  This  is  done  by  the  user  clicking 
once  on  the  ZOOM  button  and  the  mouing  the  cursor  to  the  area  that 
will  be  a  corner  of  the  area  to  be  boned.  After  depressing  and 
holding  down  on  the  botton  on  the  mouse,  the  operator  drags  the 
cursor  diagnolly  across  the  area  to  be  enlarged.  As  the  cursor  is 
being  dragged  across  the  area,  the  area  will  be  encompassed  by  a 
boK  whose  sides  are  of  dashed  lines.  Once  the  area  is  encompassed 
and  the  user  lets  up  on  the  mouse  button,  the  area  will  enpand  to 
fill  the  display  screen.  This  can  be  done  repeatedly  to  gain  finer  and 
finer  small-area  detail. 

To  return  directly  to  the  original  display  area,  as  defined  using 
the  EDIT  menu's  PRESENT  (Presentation)  SET  UP,  use  the  CLR  button  or, 
if  there  has  been  only  one  eupansion,  double  click  on  the  ZOOM 
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-BUnONS:  ZOOM  BUnON  cont.  rTN 

button.  Double  clicking  on  the  ZOOM  button  uuill  allouj  the  user  - 

to  "uialk"  up  the  eKpansions  in  the  some  order  and  using  the  some 
bondaries  as  mere  used  mhen  defining  the  smailer  ares  to  be  uiemed. 

DISPLflV,  GENERAL  NOTES 

-  INITIAL  START-UP  DISPLAY:  UJheneuer  the  system  is  initially 
pomered  up  or  the  CLR  button  is  hit,  the  screen  presentation 
displayed  to  the  uiemer  mill  be  mhat  is  termed  the  default  or  initial 
display.  This  initial  screen  presentation  mill  consist  of  the  FEBA,  the 
positions  and  identification  of  the  enemy  mobile  SAM  systems,  and 
rings  around  each  of  the  SAMs  mhich  represent  the  moKimum  range 
for  the  associated  missile.  Additionally,  the  initial  altitude 
perspectiue  of  the  OSS  mill  be  FL450,  mhich  mill  be  displayed,  along 
mith  its  AGL  counterpart,  in  the  ALTITUDE  bOK  in  the  lomer  right  hand 
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-DISPLflV,  GENERAL  NOTES:  INITIAL  START-UP  DISPLRV  cont. 
corner  of  the  display.  Positioning  of  the  SAMs  loill  be  based  on 
the  latest  auailable  real-time  intelligence  inputs  and  updated  using 
this  same  input  source.  The  initial  range  of  the  SAMs  mill  be  based 
on  the  default  starting  altitude  of  rL450  but  mill  be  tied  to  the 
altitude  perspectiue  as  shomn  in  the  ALTITUDE  bou  and  requested 
under  the  PRESENT  (PRESENTATION)  SET  UP  item  of  the  EDIT  menu. 

-  GENERAL  CONTROL  GROUPINGS  (SIM  us  OPERATIONAL):  The  DSS 
control  features,  the  MENU  headings  and  the  indiuidual  BUTTONS,  are 
roughly  diuided  into  tmo  categories.  The  first  category  is  those 
controls  that  allom  the  user  to  select  and  display  actual  real-morld 
information.  This  category  includes  oil  the  MENU  buttons  across  the 
top  of  the  display  as  mell  as  the  ZOOM  and  REAL  buttons. 

The  second  category  is  those  controls  that  allom  the  user  to  set 
up,  run,  and  eualuate  a  simulation.  This  includes  the  controls  on 
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-DISPLflV,  GENERRL  NOTES:  GENERRL  CONTROL  GROUPINGS  cont. 
the  left  side  of  the  display,  encept  the  ZOOM  button,  and  the 
SIM  button. 


-  PAGES:  The  purpose  of  this  decision  support  system  is  to 
alloiu  the  Electronic  Combat  Coordination  Officer  to  deuelop  and 
determine  the  comparitiue  worth  of  uarious  alternate  plans  for  the 
retasking  If  electronic  combat  assets.  Consequently,  there  ore 
uarious  tools  required  to  giue  the  ECCO  this  ability:  an  ability  to 
determine  uihat  has  changed  and  the  impact  of  that  change  on  the 
current  plan  (thereby  leading  the  need  to  retask),  an  ability  to 
assist  the  ECCO  in  generating  alternatiue  retasking  plans,  and  an 
ability  to  eualuate  these  aiternotiues.  These  requirements  are  met 
by  the  tools  distributed  on  the  uarious  pages  supported  by  this  OSS. 

The  QUERUIELU  page  is  the  page  currently  supported  and  glues  the 
user  the  capability  monitor  euents  and  set  up  and  run  alternatiue 
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-EDIT  MENU:  COPV  cont.  rTN 

clicking  the  mouse  button  luhile  the  cursor  is  inside  the  confines - 

of  the  bo»  mill  simultaneously  store  a  copy  of  the  object  in  the 
single-item  memory,  get  rid  of  the  bOK,  and  return  the  cursor  to 
normal  operations.  The  original  image  mill  be  unaffected. 

-  CUT 

Enables  the  selection  of  a  portion  of  the  display  and  its  deletion 
from  the  display.  CUT  factions  identically  to  CDPV,  only  the  final 
effects  differ.  The  user  selects  the  menu  item,  positions  the  cursor 
near  the  object  to  be  copied,  and,  after  first  depressing  the  mouse 
button  and  holding  it  domn,  drags  the  cursor  diagonally  across  the 
object.  Rs  the  cursor  is  being  dramn  across  the  object  a  boH  is 
formed  around  the  target.  Upon  releasing  the  mouse  button  the  boK 
stops  forming  at  that  point.  Double  clicking  the  mouse  button  luhile 
the  cursor  is  inside  the  confines  of  the  boK  mill  simultaneously 
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-EDIT  MENU:  DUPLICATE  cont. 
location.  Releasing  the  mouse  button  mill  cause  the  duplicate  td 


RTN 
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remain  at  the  last  location  it  mas  at  mhile  the  mouse  button  mas 
being  held  domn.  Double  clicking  the  mouse  button  on  the  duplicate 
mill  cause  the  duplicate  to  be  “pasted”  to  that  position. 
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-  PASTE 


Enables  the  mouement  and  permanent  positioning  of  data  that 
has  been  been  obtained  using  CUT  or  COPV.  Selecting  PASTE  after 
hauing  obtained  an  item  using  CUT  or  COPV  mill  cause  the  immediate 
appearence  of  the  Item  on  the  screen.  The  item  can  be  moued  by 
placing  the  cursor  mithin  its  confines,  holding  domn  the  mouse 
button,  and  dragging  the  item  to  its  nem  location.  Releasing  the 
mouse  button  mill  cause  the  item  to  remain  at  the  last  location  it 
mas  at  mhile  the  mouse  button  mas  being  held  domn.  Double 
clicking  the  mouse  button  on  the  item  mill  cause  the  item  to  be 
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-EDIT  MENU:  PASTE  cont.  rTN 

"pasted"  to  that  position.  - 

-  SELECT  SCREEN 

Enables  the  entire  display  to  be  selected  for  processing  such  os 
cutting  out,  copying,  duplicating,  etc.  To  function,  first  select  the 
menu  item  SELECT  SCREEN  and  then  the  menu  item  for  the  desired 
function.  On  selecting  SELECT  SCREEN  the  entire  display  mill  be 
surrounded  by  the  same  boK  seen  mhen  using  CUT,  COPY,  or 
DUPLICATE.  The  desired  process,  such  as  CUT,  mill  be  enacted 
immediately  upon  selecting  the  desired  menu  item. 

-  SHOUi  UECTOR 

Selecting  the  menu  item,  SHOLU  UECTOR,  enables  the  user  to  ueim 
information  about  a  selected  force  or  item  in  the  form  of  a  column 
of  data  belom  that  force  or  item.  This  information  uector  is 
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-EDIT  MENU:  SHOUi  UECTOR  cont.  RTN 

obtained  by  placing  the  cursor  on  the  item  of  interest  and  - 

holding  dou/n  the  mouse  button.  The  information  mill  be  mithdramn 
once  the  button  is  released. 

-  PRESENT  (PRESENTATION)  SET  UP 

This  menu  item  alloms  the  customizing  of  the  screen  display  mith 
respect  to  both  the  altitude/location  perspectiue  assumed  for  the 
display  presentation  and  the  forces/force  boundaries  presented  on 
the  display. 

—  ALTITUDE  OF  DISPLRV 

This  Item  alloms  the  user  to  define  in  one  hundred  foot  internals 
the  altitude  that  the  DSS  mill  assume  for  its  perspectiue.  This  mill 
determine  such  things  as  the  radii  of  SAM  rings  mhen  calculating 
their  range  for  presentation  on  the  display  and  the  initial  altitude  to 
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—EDIT  MENU:  PRESENT  SET  UP:  ALTITUDE  OF  DISPLAY  cont.  Rjf 

display  luhen  requesting  to  see  the  management  of  the  air  _ 

space  under  the  AIR  SPACE  CONTROL,  ALL  menu  item.  This  altitude 
can  be  measured  in  either  MSL  (Mean  Sea  Leuel)  or  RGL  (Aboue 
Ground  Leuel). 

—  DISPLAY  CENTER 

This  item  alloui  the  operator  to  select  the  center  of  the  system's 
display  and  the  area  of  couerage.  Multisensor  input  can  enable  the 
system  to  display  entire  theaters,  though  of  course  at  a  uery  lorn 
resolution  of  forces. 

—  SHOlU  FEBA  (FORIDARD  EDGE  OF  THE  BOnLE  AREA) 

This  selection  alloms  the  user  to  either  shorn  or  not  shorn  the 
FEBA  on  the  DSS  display. 
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-EDIT  MENU:  PRESENT  SET  UP  cont. 
—  FORCES  /  FORCE  BOUNDRIES 


RTN 


This  menu  item  enables  the  operator  to  customize  the  display 
presentation  mith  respect  to  the  leuel  of  the  forces  shomn  and  the 
force  boundries  presented.  The  tmo  areas  are  directly  related:  with 
Battalions  selected  as  the  force  leuel  for  presentation,  then  the 
force  boundries  that  mill  be  displayed  mill  be  Battalion  boundaries. 
There  is  also  the  capability  to  display  none  of  the  boundaries,  all  of 
the  boundaries,  or  allom  the  system  to  determine  the  leuel  of 
forces  and  force  boundaries  to  display  by  selecting  the  DEFRULT 
option.  This  latter  option  mill  result  in  the  system  selecting  and 
displaying  forces  based  on  the  area  presentation  of  the  display.  The 
smaller  the  display  area,  the  lomer  the  leuel  of  the  force  displayed. 
This  is  the  system  initial  pomer-up  setting. 


I  '  "1 


35 


THIS  IS  fl  MEHSIIRE  HF  THE  SMALL  MHC  HVPERCHRD  RRER  BELIIHI. 

-CLR 

cnouNO 

FORCES 

IRDS 

-  RTTnCK 

I  GROUP 

SUPRT/ 
AIR  CNTL 

PAGE 

p 

EDIT 

m 

HELP  ■ 

loon) 


GROUND  FORCES  MENU 


RTN 


Enables  the  control  of  the  display  of  ground  forces. 


F-4G 


EC- 

130 


EXPD 


KC- 

135 


-  RLE 

Causes  the  display  of  all  ground  forces  at  the  unit  force  leuel 
defined  by  the  EDIT:  PRESENTation  SET  UP  menu  item.  The  initial,  or 
pouier-up,  selection  of  the  force  leuel  for  the  OSS  is  the  system's 
DEFRULT  setting  (see  EDIT  MENU:  PRESENTation  SET  UP:  FORCES  /  FORCE 
BOUNORRIES).  This  is  the  initial  selection  for  display  of  forces. 


pther 


Orbit 


-  US 

Causes  the  display  of  all  US  ground  forces  at  the  unit  force  leuel 
defined  by  the  EDIT:  PRESENTation  SET  UP  menu  item.  The  initial,  or 
pomer-up,  selection  of  the  force  leuel  for  the  OSS  is  the  system's 


DEFRULT  setting  (see  EDIT  MENU: 

PRESENTation  SET  UP:  FORCES  /  FDRCE 
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-GROUND  FORCES  MENU:  US  cont. 
BOUNDRIES). 


RTN 


-  NATO 

Causes  the  display  of  all  NATO  ground  forces  at  the  unit  force 
leuel  defined  by  the  EDIT:  PRESENTation  SET  UP  menu  item.  The  initial, 
or  pomer-up,  selection  of  the  force  leuel  for  the  DSS  is  the  system's 
DEFAULT  setting  (see  EDIT  MENU:  PRESENTation  SET  UP:  FORCES  /  FDRCE 
BOUNDRIES). 


-  USSR 


Causes  the  display  of  all  USSR  ground  forces  at  the  unit  force 
leuel  defined  by  the  EDIT:  PRESENTation  SET  UP  menu  item.  The  initial, 
or  poiuer-up,  selection  of  the  force  leuel  for  the  DSS  is  the  system's 
DEFAULT  setting  (see  EDIT  MENU:  PRESENTation  SET  UP:  FORCES  /  FORCE 
BOUNDARIES). 
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GROUND  FORCES  MENU  cont. 

-  lOP  (UJflRSflUJ  PACT) 

Causes  the  display  of  all  UJP  ground  forces  at  the  unit  force  leuel 
defined  by  the  EDIT:  PRESENTation  SET  UP  menu  item.  The  initial,  or 
poiuer-up,  selection  of  the  force  leuel  for  the  DSS  is  the  system's 
DEFRULT  setting  (see  EDIT  MENU:  PRESENTation  SET  UP:  FORCES  /  FORCE 
BOUNORRIES). 

-  OTHER 

Causes  the  display  of  all  ground  forces  of  the  selected 
country(ies)  at  the  unit  force  leuel  defined  by  the  EDIT: 

PRESENTation  SET  UP  menu  item.  The  user  must  make  an  actiue 
selection  in  order  to  display  any  one  of  the  OTHER  countries  or  any 
combination  of  those  listed.  No  forces  of  the  countries  listed  under 
OTHER  mill  initially  be  displayed.  The  Initial,  or  pomer-up,  selection 
of  the  force  leuel  for  the  DSS  is  the  system's  DEFRULT  setting  (see 
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-GROUND  FORCES  MENU:  OTHER  cont. 

EDIT  MENU:  PRESENTation  SET  UP:  FORCES  /  FORCE  BOUNDARIES). 


HELP 


Selection  of  the  HELP  menu  brings  the  user  to  the  first  page  of 
the  HELP  file's  table  of  contents.  The  selection  of  any  of  these  item's 
buttons  LUill  take  the  user  directly  to  the  information  for  that 
subject  area. 

IADS  (INTEGRATED  AIR  DEFENSE  SVSTEM)  MENU 

This  menu  enables  both  the  real  time  monitoring  of  all  aspects  of 
an  enemy  IADS  operations  and  the  qualitatiue  assessment  of  the 
impact  of  EC  operations  on  the  lAOS.  These  capabilities  are 
applicable  in  either  the  REAL  (real  world)  or  the  SIM  (simulation) 
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IflDS  (INTEGRRTED  flIR  DEFENSE  SVSTEM)  cont. 
modes. 


RTN 


-  RLE 

Enables  the  presentation  of  all  the  major  components  of  an  IRDS 
as  uiell  as  their  major  characteristics:  the  air  threat,  the  SRM 
system,  RRR  systems,  the  ranges  of  their  meapons  and  radars,  and 
the  command  and  control  (C2)  interconnectiuity  of  the  system. 

-  flIR 

IDhen  implemented,  this  menu  item  mill  enable  the  display  of  the 
enemy  air  threat  enuironment.  Details  of  this  proposed  display  are 
still  being  deueloped. 

-  SRM 

The  seletion  of  this  menu  item  enables  the  presentation  of  all 
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-IHDS  (INTEGRATED  RIR  DEFENSE  SVSTEM):  SRM  cont. 

SAM  systems  in  the  area  presentation  couerage.  This  includes 
both  fiKed  and  mobile  SAMs  unless  this  menu  item  is  changed  using 
the  FIRED  or  MOBILE  modifiers,  in  this  latter  case,  the  selection  of 
one  of  the  modifiers  mill  eliminate  the  presentation  of  the  other 
class  of  systems.  The  presentation  of  SAMs  Luili  include  the  system's 
numerical  designation  and  its  uieapon's  maKimum  leathal  range 
giuen  the  altitude  perspectiue  of  the  DSS  (see  EDIT:  PRESENTation  SET 
UP). 

-  AAR 

AAA  systems  mill  be  shomn  in  the  same  manner  and  mith  the 
some  modifications  and  restrictions  as  are  SAMs.  This  portion  of  the 
system  is  not  currently  ready  for  display  or  implementation. 
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IflDS  (INTEGRATED  AIR  DEFENSE  SYSTEM)  cont.  RTN 

-  FIRED  and  MOBILE  .l 

These  menu  items  are  selected  prior  to  the  selection  of  the 
categories  they  modify,  SAM  and  AAA,  and  do  not  haue  an 
independent  function.  They  enist  solely  to  modify  the  ground  threat 
categories. 

-  SAM  RNG  (RANGE)  and  ARA  RNG  (RANGE) 

Enables  the  display  of  lueapon  ranges  for  both  types  of  threat. 
This  is  the  default  category  of  display  during  most  selections  to 
display  either  threat.  Selection  of  the  RNG  menu  item  mill 
automatically  display  all  classes  of  the  type  threat  requested,  i.  e. 
SAMs,  mith  the  lethal  range  of  each  system,  giuen  the  altitude 
perspectiue  of  the  DSS  at  the  time. 
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IADS  (INTEGRATED  AIR  DEFENSE  SVSTEM)  cont.  rTN 

-  S  (SHM)-RRDRR  and  A  (HnA)-RRDAR  L__ 

Enables  the  display  of  probability  of  detection  ranges  for  both 
types  of  threat.  These  ranges  are  base  on  the  radar  cross  section  of 
the  aircraft  and  the  percent  probability  selected  as  the  probability 
of  detection.  The  default  probability  of  detection  is  507..  Other 
probabilities  for  detection  may  be  set  by  annotating  the  querey 
page  that  appears  upon  the  user  selecting  this  menu  item.  Once  the 
probability  of  detection  is  set,  the  system  ujill  automatically  display 
all  classes  of  the  type  threat  requested,  i.  e.  SAMs,  loith  the  range 
of  each  system,  giuen  the  altitude  perspectiue  of  the  DSS  at  the 
time. 

-  EID  (EARLV  UiARNING  RADARS)  and  GCI  (GROUND  CONTROL  INTERCEPT 
RAOARS) 

Enables  the  display  of  probabilitu  of  detection  ranges  for  both 
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-IHDS  (INTEGRATED  AIR  DEFENSE  SVSTEM):  EUJ  and  GCI  cont.  rtn 

types  of  radar  systems.  These  ranges  are  base  on  the  radar  - 

cross  section  of  the  aircraft  and  the  percent  probability  selected  as 
the  probability  of  detection.  The  default  probability  of  detection  is 
507o.  Other  probabilities  for  detection  may  be  set  by  annotating  the 
querey  page  that  appears  upon  the  user  selecting  this  menu  item. 
Once  the  probability  of  detection  is  set,  the  system  luill 
automatically  display  all  sites  of  the  type  radar  requested  and  their 
associated  detection  range  ring,  giuen  the  altitude  perspectiue  of 
the  DSS  at  the  time. 

-  C2  (COMMAND  AND  CONTROL) 

The  selection  of  this  menu  item  alloujs  the  depiction  of  the  enemy 
IADS  command  and  control  interconnectiuity,  primarily  in  the  form 
of  communications  interconnectiuity.  It  enables  both  the  real-time 
real-ujorld  monitoring  and  eualuation  of  effects  due  to  EC 
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-IHDS  (INTEGRATED  flIR  DEFENSE  SVSTEM):  C2  cont.  rTN 

operations  as  uiell  as  the  monitoring  and  eualuation  of  the  - 

effectiueness  of  proposed  EC  operations  using  simulation  techniques. 
Upon  selecting  this  menu  item  there  luill  be  displaged  the 
interconnectiuity  of  the  displayed  IRDS  components  using  block  lines 
to  depict  cable  connection  between  points  and  fuzzy  gray  lines  to 
indicate  HF/DHF/UHF  connections.  Disruption  of  these  connections 
will  be  shown  as  breaks  in  the  lines:  hard  wire  disruptions  will  be 
depicted  as  a  single  large  break  at  about  the  midpoint  of  the 
connection;  disruption  of  radio  connections  will  be  depicted  as 
increasingly  widening  dashed  lines  to  depicted  increasing  degrees  of 
deterioration  of  the  communications  link. 
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NT  BK  (NOTE  BOOK  /  HOOK  BOOK)  MENU 
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The  NOTE  BOOK  feature  of  this  menu  alloms  the  user  to  put  aside 
personal  notes  for  purposes  such  as  a  memory  aid.  The  HOOK  BOOK 
feature  alloujs  the  direct  input  of  suggestions  to  the  design  team 
for  the  improuement  and  euolution  of  the  DSS  as  an  interagal  part  of 
the  adaptiue  design  process.  The  importance  of  HOOK  BOOK  entries  is 
that  they  are  the  basis  of  requirements  for  future  modules  of  the 
euoluing  DSS  and  mill  therefore  determine  the  future  capabilities 
and  characteristics  of  the  DSS  as  it  grows  into  its  uarious  other 
areas  of  operations. 

The  second  portion  of  the  menu  consists  of  the  controls  auailable 
to  the  operator  for  the  storage  and  access  of  the  NOTE  BOOK  and 
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-NT  BK  (NOTE  BOOK  /  HOOK  BOOK)  MENU:  SHUE  cont.  RTI 

file  you  are  currently  luorking  in.  The  system  ujMI  automatically - 

ask  if  you  mould  like  to  store  unsaued  changes  and  mill  require  you 
to  name  those  files  not  preuiously  named. 

-  SRUE  flS 

Enables  the  storage  of  information  in  a  nem  file  mithout  hauing 
to  close  the  current  file.  The  system  mill  automatically  ask  if  you 
mould  like  to  store  unsaued  changes. 

SUPRT  (SUPPORT)  /  niR  CNTL  (CONTROL)  MENU 

The  items  of  this  menu  are  primarily  designed  to  support 
information  needs  concerning  support  resources,  assessing  air 
space  usage  to  support  retasking  mission  generation,  and 
operational  guidence.  Rlso,  the  uast  majority  of  these  aids  haue 
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not  been  constructed  and  therefore  are  not  shoiun  at  this  time.  I - 

Rn  initial  rough  proposal  ujill  be  giuen  for  the  porpose  of  generating 
comments  on  LUhich  to  build  the  requirements  for  these  aids. 

-  BRSES,  RIR  REFUEL,  SRR  (SERRCH  RND  RESCUE) 

Giues  information  on  the  status  and  support  capabilities  of  bases, 
air  refueling  assets,  and  SRR  assets.  The  operator  is  able  to  access 
data  using  uarious  sort  requirements.  The  information  required  on 
uiithin  these  areas  to  support  the  ECCO's  retasking  mission  haue  not 
been  determined.  Suggestions  as  to  the  information  needed  by  the 
ECCO  to  do  retasking  are  welcomed. 
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SUPRT  (SUPPORT)  /  RIR  CNTL  (CONTROL)  MENU  cont.  RTN 

-  RIR  SPACE  CNTL  (CONTROL)  I— — 

—  RLL 

Enables  the  simultaneous  display  of  all  listed  uses  of  airspace 
ouer  the  battlefield.  These  uses  include  minimum  risk  ingress/ 
egress  corridors,  airspace  used  for  artillery  and  naual  gunfire,  and 
the  command  status  of  the  flir  Defense  Artillery  couering  a  giuen 
area  of  airspace.  All  RIR  SPACE  CNTL  pages  giue  the  operator  actiue, 
continuous  control  of  the  altittude  being  used  to  driue  the  OSS 
display  of  the  airspace  usage  as  uiell  as  an  identical  control  to 
control  the  time,  from  the  present  to  24  hours  in  the  future,  of  the 
presentation.  This  alloius  the  user  the  ability  to  uiem  airspace  usage 
as  it  changes  uertically  mith  altitude  and  as  it  changes  (planned) 
luith  time. 


ACT 


Til 

IS  IS  n  MEnSUIIE  ue  the  smiill  miic  iiypehciiiiu  iiiieh  beluiu. 

■CLR 

GROUND 

FORCES 

IRDS 

RTTHCK 
:  GROUP 

SUPRT/ 
AIR  CNTL 

PRGE 

EDIT 

NT 

BK 

HELP  ■ 

loom 


EF- 
1 1  1 


F-4G 


EC- 

130 


EXPD 


KC- 

135 


bther 


Orbit 


Fiy 

Path 


RTN 


SUPRT/HIR  CNTL  MENU:  flIR  SPRCE  CNTL  cont. 

—  CORRIDORS 

Enables  the  display  of  current  and  planned  minimum  risk  ingress/ 
egress  corridors.  Rdditionally,  these  can  be  uiemed  ouer  altitude 
and  time.  Rll  RIR  SPACE  CNTL  pages  giue  the  operator  actiue, 
continuous  control  of  the  altittude  being  used  to  driue  the  OSS 
display  of  the  airspace  usage  as  mell  as  an  identical  control  to 
control  the  time,  from  the  present  to  24  hours  in  the  future,  of  the 
presentation.  This  alloms  the  user  the  ability  to  uiem  airspace  usage 
as  it  changes  uertically  ujith  altitude  and  as  it  changes  (planned) 
mith  time. 

—  RRTV  (HRTILLERV)  /  NflURL  (gunfire) 

Enables  the  display  of  those  airspaces  being  used  for  or  planned 
for  allied  artillery  and  naual  gunfire.  Rdditionally,  these  can  be 
uiemed  ouer  altitude  and  time,  fill  RIR  SPACE  CNTL  pages  giue  the 
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— SUPRT/flIR  CNTL  MENU:  RRTV  /  NflURL  (gunfire)  cont. 
operator  actiue,  continuous  control  of  the  altittude  being  used 
driue  the  DSS  display  of  the  airspace  usage  as  luell  as  an  identical 
control  to  control  the  time,  from  the  present  to  24  hours  in  the 
future,  of  the  presentation.  This  alloms  the  user  the  ability  to  uieiu 
airspace  usage  as  it  changes  uertically  luith  altitude  and  as  it 
changes  (plannedimith  time. 

--  ROES,  CMD  GUID  (COMMAND  and  COMMANDER'S  GUIDENCE),  and 
MSN  OBJ  (MISSION  OBJECTIUES) 

These  are  computer-based  documents  set  up  to  allom  the  easy 
sorting  and  accessing  of  information  concerning  the  many  aspects 
couered  by  these  three  areas.  They  are  intended  to  be  used  by  the 
ECCO  during  retasking  mission  planning  as  guides  to  the  ouerall 
objectiues  and  the  limiting  constraints. 


ACT 


52 


A p pend IX  C  Hook  Bo(jk 


I  ntrod  Liction 

The  purpose  of  a  Hook  Book  is  to  gather  thoughts,  needs, 
criticisms,  recommendations,  and  various  other  inputs  over  time  so 
that  basic  trends  can  be  determined.  This  is  possible  because  the 
realization  of  a  need,  or  an  idea  of  how  to  solve  a  problem,  or  the 
realization  of  the  core  of  a  problem,  for  example,  will  surface 
repeatedly  over  time.  The  problem  is  that  these  realizations  will 
lake  on  many  different  manifestations  due  to  the  specific  subject 
being  addressed  at  the  moment  or  the  specific  stimulus  that  triggers 
the  thoughts.  Additionally,  due  to  the  time  and  number  of  events 
happening  between  the  occurrence  of  like  ideas,  it  is  difficult  for  an 
individual  to  mentally  track  the  development  of  a  pattern  or  trend. 
These  apparently  random  and  unrelated  thoughts  therefore  can 
ultimately  be  grouped  and  filtered  into  coherent  associations  of  ideas 
only  if  gathered  in  a  systematic  manner  and  only  if  viewed  over  a 
period  of  time,  such  as  three  months.  This  will  point  out  those  major 
areas  of  concern,  maturing  ideas,  long  term  needs,  and  any  number 
of  other  subject  areas. 

The  identification  of  future  needs  and  the  directions  of  future 
expansion  are  key  elements  in  the  adaptive  design  process.  The  use 
of  the  hook  book  therefore  becomes  crucial  to  the  process  of  adaptive 
design  by  more  clearly  defining  these  future  needs  and  directions  of 
expansion.  Specific  areas  of  interest  that  were  tracked  during  this 
research  were: 

1)  'Fhe  use  of  a  computer-based  approach  for  the 
storyboarding  process, 

2)  Future  research  for  the  specific  DSS, 


3)  Ideas  on  ihe  impact  of  the  DSS, 


4)  Adaptive  design, 

5)  The  user  development  of  storyboards. 

A  technique  using  note  cards  to  record  ideas  as  they  occurred 
was  employed  in  this  research  as  the  hook  book.  The  note  card 
based  hook  book  had  a  specific  format  which  required  the  notation 
of; 


1)  The  thought  or  information, 

2)  The  general  subject  area  or  title  of  the 
thoughts/information, 

3)  The  date  on  which  the  notation  was  made, 

4)  The  circumstances  which  triggered  the  thought  are  also 
noted  so  that  a  reference  or  framework  can  be  established  for  the 
thought  (43). 

Recording  tlioughts  and  other  information  in  this  manner  allowed  the 
later  determination  of  trends  over  time.  The  format  of  each  subject 
area  in  this  appendix  follows  this  same  chronological  arrangement  to 
show  the  reader  the  same  development  of  ideas  over  time  and  how 
the  various  conclusions  in  Chapter  Four  were  arrived  at. 

Three  major  areas  developed  as  a  result  of  using  a  hook  book 
and  tracking  the  thoughts  and  realizations  that  occurred  over  the 
period  of  this  research.  These  three  areas  of  ideas  establish  the 
major  sections  of  this  appendix: 

1)  Organizational  Impact, 

2)  Decision  Support  Systems  and  the  Adaptive  Design  Process, 


3)  The  ECCO  DSS  and  Its  environment. 


Organizaiional  1  m  pad. 


It  is  the  opinion  of  former  USAF  Cliief  of  Staff  General  Welsh 
that  the  value  of  optimization  techniques  to  aid  in  the  command  and 
control  of  war  is  generally  questiona‘^le.  'Inis  is  due  to  the  fact  that 
war  is  inherently  wasteful  and  the  margins  of  error  are  very  gross 
while  optimizing  control  or  efficiency  is  concerned  with  making 
finely  defined  and  constrained  choices  at  the  margins  (48). 

While  gross  margins  of  error  are  obviously  true  in  the  general 
conduct  of  war,  in  the  area  of  electronic  combat  the  margins  of 
victory  or  defeat  are  more  tightly  defined,  as  in  the  few  seconds  of 
delay  in  the  actions  of  an  opponent  to  engage  friendly  attacking 
forces.  The  better  able  an  organization  is  at  adapting  its  EC  packages 
to  the  changing  environment  and  optimizing  their  effectiveness 
against  an  opponent,  the  greater  the  possibility  of  mission  success. 
Even  so,  what  other  impact  will  a  DSS  have  on  an  organization  at  the 
same  time  it  is  increasing  its  effectiveness?  In  answer,  this  section 
is  divided  into  five  parts  to  discuss  issues  in  the  following  areas: 

1)  Command/Mission  Impact 

2)  Command  Structure  Impact 

3)  TACS  Capability/Structure 

4)  Use  of  Expert  Systems  (AI)  in  DSS 

5)  Miscellaneous 

Com mand  /  Mission  1  m pact. 


1)  8  AUG  87:  COMMAND  AIDING:  'I  hough  the  concept  of  aiding  the 
mission  planning  process  (force  and  unit  levels)  appears  to  be  well 
on  its  way.  HOW  DO  YOU  AID  ''HE  CC  (commander)  DURING  MISSION 
EMPLOYMEN'I?  CAN  I’l  IE  b’ORCE  CC  IMPACF  TI  IE  MISSION  VERY 


MUCH  ONCH  THE  MISSION  IS  OVER  THE  ED  (line  of  departure)  AND 
INTO  THE  FRAY?  While  it  appears  that  if  these  decisions  can  be 
made  and  executed  quickly  enough  then  this  can  be  done  by  trading 
between  packages,  it  isn't  clear  that  this  w'ould  be  a  good  idea  once 
the  units  are  already  or  nearly  ready  to  execute  final  actions.  ,  such 
as  entry  into  the  target  area. 

2)  -  ---  IMPACT  ON  OPERATIONS:  How  does  speeding  up  the 
planning/decision  making  process  impact  the  organization?  In 
general  (all  things  working  in  theoryf!))  this  will  allow  the 
commander  to  take  the  initiative,  take  advantage  of  opportunities, 
be  FLEXIBLE. 

3)  20  JAN  88;  IMPACT  ON  OPERATIONS;  Due  to  the  near  equality 
of  forces  (on  a  front  such  as  NATO  -  WP  front),  only  way  to  beat  the 
enemy  is  flexibility,  BUT  if  the  idea  of  retasking  is  anathema  in 
many  operational  agencies  how  can  we  be  flexible?  How  do  we 
exercise  the  concepts  of  Mass  (concentration)  of  Force,  of  Maneuver, 
of  Ecottomy  of  Force? 

4)  2  FEB  88:  LIMIT  OF  AID  USEFULNESS:  There  is  a  point  in  a 
mission  that  a  crew'  CAN  NOT  respond  to  redirection  (regardless  of 
the  capability  to  get  them  the  needed  information  and  reconfigure 
the  aircraft)  without  putting  themselves  and  others  in  greater  peril 
tlian  if  they  just  follow  through  with  the  mission.  THEREFORE,  will 
the  introduction  of  a  real-time  retasking  DSS  lead  to  the  command 
structure  trying  to  retask  after  some  NO-CAN-DO  point  and  thereby 
cause  greater  loss  and  problems  than  it  will  solve?  How  can  this 
point  be  determined  with  any  reliability? 

5)  25  FEB  88:  AID  USEFULNESS  AND  ORIENTATION;  Do  we  want  to 
aid  the  mission  employment  of  assets  even  if  we  can?  Why  even 
bother  to  ask  this  question?  Even  if  there  are  the  systems  to 
overcome  all  the  input  and  execution  problems,  the  commander  is 
limited,  in  terms  of  time,  in  his  ability  to  complete  the  decision 
cycle  and  the  crew  is  similarly  limited  in  their  ability  to  react  to 


conuiiand  retasking  even  if  they  are  given  the  correct  inforinatiot). 
Also,  there  is  a  point  past  which  a  change  will  create  greater 
problems  and  cause  greater  loss  than  following  through  with  the 
original  mission  or  giving  the  crews  a  NO  GO  due  to  the  fact  that  the 
attack  they  are  supporting  has  been  cancelled.  THUS:  real-time 
retasking  CAN  be  used  and  DOES  need  to  be  developed  (carefully),  it 
seems  the  area  to  really  concentrate  in  order  to  gain  the  greatest  pay 
back  by  giving  the  commander  flexibility  would  be  reducing  the 
sense/decision/execution  cycle  at  the  TACC/ATAF  level  down  to  the 
area  of  3  to  6  hours.  This  would  allow  the  commander  to  respond  to 
operational  level  opportunities,  which  are  generally  of  greater 
significance  than  tactical,  while  retasking  could  affect  tactical  efforts. 

6)  2  MAR  88:  COMMAND  AIDING:  There  is  a  serious  misuse  of  the 
of  the  EC- 130  because  AIR  COMMANDERS  DO  NOT  UNDERSTAND  THE 
MISSION  OF  THE  EC- 130,  HOW  IT  SHOULD  BE  EMPLOYED  TO 
ACCOMPLISH  ITS  DOCTRINALLY  DEFINED  MISSION,  AND  THE  TRUE 
IMPACT  OF  THAT  MISSION  ON  THE  POTENTIAL  FOR  THE  SUCCESS  OF 
FRIENDLY  I-'ORCES.  To  assure  the  proper  use  of  the  EC-130  as  well  as 
other  forces,  any  decision  aid  such  as  the  ECCO  DSS  should  have 
extensive  memory  aids  on  equipment  specific  capabilities,  doctrine, 
limitations,  and  so  on.  This  may  help  improve  the  employment  of 
individual  systems  and  thereby  increased  effectiveness  of  the  overall 
force. 


The  upshot  of  these  previous  entries  are  that  retasking  can  be 
a  valuable  tool  within  recognized  confines  but  it  may  not  be  the  place 
to  center  the  greatest  efforts  for  flexible  force  command  due  to 
mainly  human  litnitations  (at  least  while  there  is  a  human  is  still 
flying  the  aircraft  and  the  role  of  "pilot”  has  not  yet  been  assumed  by 
remotely  piloted  vehicles).  Rctasking  may  be  constrained  due  to  the 
limited  time  in  which  a  retasking  decision  must  be  made, 
communicated,  and  executed  in  theaters  like  NAd’O  or  Korea  and  the 
time  required  for  humans  to  digest  even  the  best  information  and  act 
on  it.  Ihe  greater  usefulness,  and  therefore  greater  pay  off,  may  be 
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the  coniinaiid  decision  cycle  iliat  culminates  in  the  generation  of  the 
Al'O  and  its  execution.  Decreasing  this  latter  cycle  to  three  to  six 
hours  would  allow  the  air  component  comntander  to  mould  the 
theater  tactical  and  operational  battles  while  leaving  the  aircraft 
tactical  battles  to  be  fought  by  the  crews.  History  testifies  to  the 
soundness  of  individual  aircraft  combat  tactics  but  is  less  convincitig 
as  to  the  strength  of  higher  levels  concepts.  This  would  include  such 
areas  as  the  coordinated  employment  of  EC  assets  in  support  of  task 
force  level  operations.  All  levels  of  combat  must  be  won  to  win  the 
war  as  well  as  the  battle.  Consequently,  the  responsiveness  of  the 
command  cycle  at  the  theater  tactical/operational  level  appears  to  be 
the  area  of  greatest  pay  off  and  consequently  the  area  to  focus  on 
first  with  retasking  as  a  parallel  but  slightly  lower  priority. 

Com  mand  Structure  Impact. 

1)  23  SEPT  87:  COMMAND  LOCATION:  Where  do  you  put  the 
command  point  for  the  C2  of  EC  assets?  Due  to  the  scarcity  of  EC 
assets,  the  commander  only  has  the  flexible  tactical/operational 
control  (terms  used  in  the  sense  of  tactical-operational-strategic) 
necessary  to  take  advantage  of  opportunities  and  react  to  enemy 
threats  at  the  theater  level.  Therefore,  C2  of  EC  assets  must  be  at 
the  theater  or  AAFCE  level.  PROBLEM :  AAFCE  works  the  strategic 
level/allocation  of  resources  and  NOT  the  current  battle.  HOW  MIX? 

2)  23  SEPT  87:  COMMAND  LOCATION:  In  constructing  the  C2 
structure,  where  do  you  put  the  control?  ABCCC  (Airborne 
Command  and  Control  Center)  for  its  LOS  (line  of  sight)  capability? 
Borefink?  ATAF?  ATOC? 

3)  24  SEPT  87:  OBJECTIVES:  Tasking  and  therefore  retasking  MUST 
be  in  line  with  the  Air  Commander's  objectives  which  are  in  turn 
supporting  the  Ground  Commander's  objectives. 


4)  25  SEPT  87:  COMMAND  LOCATION:  The  ABCCC  works  the  mr 
ground  mission  areas,  AWACS  works  the  air-air  mission  arca‘^. 


Given  these  divisions,  the  ECCO  should  go  on  ABCCC  if  he  is  to  be  put 
^  into  the  air  (with  consideration  of  operating  world  wide,  position 

should  be  in  air  as  well  as  on  ground  for  NATO  as  this  results  in  the 
system  being  redundant  and  survivable). 

5)  25  SEPT  87:  COMMAND  LOCATION:  Who  should  have  authority 
^  of  this  very  scarce  asset?  Must  support  overall  goals  of  theater 

commander  and  therefore  be  able  to  shift  EC  assets  across  command 
lines  within  theater  (example:  NATO)  and  yet  be  in  position  to 
monitor/execute  tactical  operations.  For  operations  outside  of  NATO 
this  does  not  appear  to  be  a  problem  as  is  only  a  single  air  forces 
commander  whereas  in  NATO  is  several  ATAFs  where  may  need  to 
shift  forces  among  these  and  this  must  be  done  by  an  authority  with 

a  broader  view  than  a  single  ATAF  commander. 

C 

It  would  seem  that  in  theaters  where  there  is  only  a  single  air 
force  component  commander  that  the  question  of  where  to  position 
the  ECCO  is  not  really  a  problem.  In  NATO,  with  its  multiple  ATAF 
^  commanders  each  tasked  with  responsibilities,  there  is  a  problem  of 

shifting  assets  among  the  ATAFs  because  it  is  not  likely  that  one 
commander,  hard  pressed  with  what  he  does  have,  is  going  to  freely 
and  quickly  release  operational  control  of  assets.  In  NATO  this  is  a 
^  political  as  well  as  military  problem. 

TAGS  Capability  /  Structure. 


1)  23  SEPT  87:  C2  RESTRUCTURING:  To  accomplish  retasking  the  C2 
structure  must  be  changed  to  support: 

How  do  you  determine  that  there  is  a  problem  and 
communicate  with  EC  assets?  INPUT:  real-time  intelligence  feeds, 
JTIDS  communications  with  forces  PROCESS:  filter  information 
through  threshold  triggers  to  check  for  problems  such  as  loss  of 
forces  or  unexpected  increases  in  threat  level. 


;•  -  How  advise  commander  as  to  better/best  way  to  use  assets? 

I  Use  of  DSS  should  enable  the  analysis  of  user-developed  alternatives 

I 

I 
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to  determine  better  ways  of  using  EC  assets  under  a  changing 
environment. 

How  do  you  redefine  airspace/ADA  status  to  enable  the 
dynamic  use  of  EC  assets?  Requires  a  rapid,  secure,  fully  integrated 
joint/combined  communications  capability.  The  current 
manifestation  of  JTIDS  is  an  initial  step  in  the  direction  of 
accomplishing  such  an  objective. 

-  How  do  you  give  airborne  crews  a  new  mission  so  that  they 
can  execute  it  with  as  great  a  potential  for  success  as  if  it  had  been 
planned  under  the  normal  planning  process?  Requires  that  the  crew 
have  all  route,  communications,  coordination,  and  target 
information  to  include  route/  target  area/target  study.  Again,  JTIDS 
is  an  initial  step  toward  this  and  will  be  even  more  applicable  with 
the  preplanned  improvement  which  allows  the  in-flight  modification 
of  the  displayed  routes  and  boundaries.  This  does  not  address 
getting  the  crew  the  type  of  route  and  target/target  area  study 
needed  to  determine  crew/team/unit  tactics  and  the  preflight 
coordination  among  crews  necessary  to  execute  those  tactics.  While 
JTIDS  may  again  be  able  to  give  the  communication  capabilities 
needed  to  overcome  these  hurdles,  there  is  a  very  real  question  as 
to  whether  or  not  there  will  be  the  time  to  do  all  this  coordination 
(18;  23). 

How  do  you  reconfigure  an  asset's  on-board  EC  equipment/ 
weapons/expendables  for  a  retasked  mission  OR  does  this  become  a 
planning  constraint  for  retasking? 

-  How  do  you  assess  the  potential  for  EC/hard  kill  fratricide 
and  then  coordinate  to  minimize  it? 

2)  24  SEPT  87:  C2  REQUIREMENTS:  JTIDS  offers  solution  to  the 
need  of  a  secure,  high  data  rate  communications  capability  BUT  is  it 
built  with  reliability/survivability  and  is  there  a  second  system 


(backup,  redundant)  with  the  same  characteristics?  If  there  isn't  a 
"backup  JTIDS,"  what  capability  do  we  have  to  operate  without  it? 


The  impact  of  these  thoughts  are  that  the  ECCO  DSS  is  worthless 
without  these  kinds  of  TAGS  modifications  to  give  the  commander 
the  capability  to  do  retasking.  Similarly,  if  retasking  is  to  be 
pursued  and  the  types  of  system  changes  as  mentioned  above  are 
instituted,  then  it  is  absolutely  critical  that  something  like  the  ECCO 
DSS  be  planned  for  and  constructed  so  as  to  enable  the  commander's 
staff  to  generate  intelligent  plans  and  options  for  the  commander  to 
consider  as  needed. 

Use  of  Expert  Systems  ( Al)  in  DSS. 

1)  8  NOV  87:  USER  ACCEPTANCE:  Will  users  accept  DSS 
determinations/conclusions/recommendations?  The  DSS  must  have 
the  capacity  to  explain  those  things  which  are  derived  conclusions 
and  more  than  just  complicated  number  crunching  (For  example: 
Though  a  route  looks  good  with  the  critical  IADS  nodes  destroyed, 
route  Pk  is  shown  as  0.58.  WHY?  The  route  overflies  the  general 
assembly  area  of  a  armored  division  with  its  heavily  reinforced  air 
defense  units  and  the  terrain  is  composed  of  open  stretches  of  flat 
terrain  giving  the  mobile  SA-6/-8/-etc.s  very  good  chances  of 
successfully  utilizing  their  full  capability  for  autonomous  acquisition 
and  engagement.). 

2)  8  NOV  87:  IMPLICATIONS:  DOES  VERY  USE  OF  EXPERT  SYSTEM 
ERODE  HUMAN  EXPERTISE  DEVELOPMENT  even  while  explanation 
capability  of  AI  system  may  win  user  acceptance?  Does  human  user 
understand  WHY  the  particular  rules  where  chosen  and  fired  in  the 
order  they  were  fired  in  if  he  hasn't  spent  time  "in  the  dirt"  to  find 
out  for  himself?  OR  will  AI  allow  for  the  building  of  further 
expertise  on  an  AI  expert  system  foundation? 

3)  10  FEB  88:  IMPLICATIONS:  If  DSS  and/or  expert  system  is  fully 
accepted  by  a  unit,  what  is  the  effect  on  the  units  ability  to 


186 


operate/survive  if  the  system(s)  goes  down?  How  does  this  affect 
the  ability  of  people  to  gain  their  own  experience  to  gain  insight  on  a 
problem  and  develop  their  own  thoughts  on  a  subject  (30;  41). 

These  are  areas  of  great  concern  as  it  is  very  important  that 
the  operation  of  those  systems  be  understood  so  as  to  fully  utilize 
their  potential.  Also,  the  complete  understanding  of  these  systems 
is  of  even  greater  importance  when  the  systems  are  lost  due  to  battle 
damage  and  the  C2  system  must  once  again  fall  back  on  human 
operators.  This  is  an  area  for  further,  basic  research. 

Miscellaneous  (but  Important). 

1)  29  SEPT  87:  OPERATIONS  IMPACT:  What  are  the  effects  on  a 
coordinated  operation  and  the  commander’s  ability  to  successfully 
pursue  the  battle  if  the  DSS  is  down  due  to  hasty  movement  (planned 
movement  should  include  the  operation  of  an  alternate  system)? 

Due  to  destruction?  The  answer  to  this  question  helps  establish  the 
system's  value  and  therefore  the  level  of  means  appropriate  to  keep 
it  in  operation. 

2)  18  NOV  87:  MANAGEMENT  OF  ADAPTIVE  DESIGN:  How  does 
"the  system"  (the  USAF  support  system)  manage  the  development 
and  support  of  an  adaptively  designed  system?  Adaptive  design 
should  be  done  on  site  with  the  users  BUT  if  the  system  is  used 
throughout  the  Air  Force  (i.e.,  world  wide)  and  in  a  variety  of  specific 
applications,  then  WHO  decides  WHAT  changes  will  be  implemented 
WHEN? 

s 

Proposal  for  implementation:  User  submits  a  desired  change  to  a 
local  DSS  referee  who  sits  at  no  higher  level  than  the  directorate 
above  the  unit  (flying  squadron  submits  request  to  DO  referee).  The 
referee  is  a  former  user  of  the  systems  and  can  see  their  use  across 
the  other  unit  of  the  directorate  within  the  wing.  The  directorate 
referee  is  on-line  with  other  wing-level  referees  who  evaluate  the 
suggestion  and  submit  it  up  to  command  headquarters  for  review 
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and  approval  before  recommendation  to  the  AFSC/AFLC  OPR.  This 
evaluation  requires  that  support  and  integration  of  the  system  be 
considered.  To  be  responsive  there  is  a  45  day  time  limit  on  this 
process.  PROBLEMS:  This  introduces  another  tremendous  (and 
generally  unwanted/unneeded)  bureaucracy  into  the  military.  The 
momentum  toward  standardization  would  nullify  the  advantage  of 
adaptive  design  which  is  the  direct  implementation  of  a  system 
tailored  to  that  specific  user’s/unit's  needs.  Standardization  would 
leave  the  user  with  a  system  that  was  a  compromise  of  the  needs  of 
all  other  units.  With  the  world-wide  mission  of  the  Air  Force  and  its 
requirement  for  personnel  interchangeability,  is  this  compromise 
not  inevitable?  PROPOSAL:  The  Air  Force  might  adopt  the 
philosophy  of  portability,  borrowed  from  the  field  of  computer 
science,  to  avoid  undesirable  compromise,  make  the  adaptive  design 
process  workable,  and  retain  the  advantages  of  a  system  responsive 
to  the  needs  of  the  LOCAL  user.  Portability  first  provides  a  core 
structure  which  is  standard  throughout  the  Air  Force  and  controlled 
at  the  Air  Force  level.  This  core  then  supports  the  unique 
capabilities  of  a  command  or  theater  by  the  addition  of  a  layer 
external  to  the  core.  This  additional  layer  is  controlled  by  the 
particular  command  or  theater  it  was  built  to  support.  Finally,  this 
command-customized  system  supports  further  customization  by 
individual  units  to  do  the  unique  job  these  units  have  been  assigned 
to  accomplish. 


3)  12  JAN  88:  DYNAMIC  RECONFIGURATION:  How  can  required  in¬ 
flight  reconfiguration  of  mission  assets  be  accomplished? 


DSS  and  the  Adaptive  Design  Process 


This  second,  more  theoretically  oriented, 
into  the  the  following  four  parts: 


section  is  divided 
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1)  Capturing  User  Input, 

2)  Adaptive  DSS  Design, 

3)  Follow  -  on  Research:  General, 

4)  DSS  Evaluation  of  Operations. 

Capturing  User  Input.  The  user  and  his/her  organization  are 
the  best  source  for  generating  the  requirements  for  whatever 
support  systems  they  may  need  to  accomplish  the  tasks  they  have 
been  given.  Consequently,  the  capture  of  this  information  becomes 
very  important.  As  mentioned  previously  in  this  thesis,  past  efforts 
have  shown  that  the  one-time  questioning  of  users  as  to  their  needs, 
and  other  similar  techniques,  generally  leads  to  unsatisfactory 
results.  Additional  research,  also  previously  mentioned,  has  shown 
that  data  gathered  over  time  enables  the  establishment  of  truer  basic 
needs  by  overcoming  problems  of  human  perception  like 
remembering  yesterday's  problem  instead  of  the  problem  that 
continually  reoccurs.  The  question  then  becomes  how  to  gather  this 
information  while  interfering  the  least  with  the  user's  job  at  hand 
and  retaining  the  context  of  the  problem. 

1)  27  AUG  87:  REQUIREMENTS  CAPTURE:  Need  to  allow  user 
ideas/complaints/recommendations/etc.  to  be  noted  with  minimal 
cognitive  interruption  of  current  task.  HOW?  Might  use  light  boom 
mike  on  head  set  with  foot  mike  to  allow  user  to  "think  out  loud." 
Could  also  hook  up  to  DSS  for  audio  prompts  and  other  information 
(22). 

2)  8  NOV  87:  SYSTEM  ENVIRONMENT:  Use  of  HyperCard -like 
environment  (An  environment  links  the  tools,  capabilities,  data, 

and  models  of  a  system)  -  Build  the  DSS  so  that  the  user  can't  change 
the  system  permanently  but  give  the  user  the  ability  to  duplicate 
panels  and  then  change/write  on  the  duplicates  to  show  what  is 
desired.  OR/AND  -  allow  the  user  to  make  a  temporary  change  to  the 
operating  system  by  inserting  the  changed  "card"  or  commanding  a 
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system  change.  These  effects  would  be  deleted  on  command  or  on 
turning  the  system  off  or  on  resetting  the  system, 

3)  18  NOV  87:  SYSTEM  ENVIRONMENT:  Use  a  HyperCard-like 
environment  in  an  operational  system  to  pull  in  and  run  operations 
(models,  data  bases,  spread  sheets,  etc.)  -  USER  enabled  to  take 
snap-shot  of  screen  and  modify,  write  on,  etc.  and  send  off  to  store 
for  later  evaluation. 

4)  18  NOV  87:  SYSTEM  ENVIRONMENT:  It  would  be  best  to  have  a 
software  environment  which  supports  a  full-up  operation  as  well  as 
storyboards/functional  display.  This  would  then  allow  the  evolution 
of  a  system  from  storyboards  to  operating  system,  the  direct 
comparison  of  the  desired  system  versus  the  delivered  system,  and 
allow  the  creation  of  storyboards  from  the  current  operational 
system  to  annotate  desired  changes. 

5)  18  NOV  87:  REQUIREMENTS  CAPTURE:  Snap-shot  of  screen  used 
to  capture  user  requirements  should  automatically  be  annotated  with 
the  date  and  time,  the  ability  for  the  user  to  link  to  other  cards  to 
show  a  desired  sequencing,  and  a  place  to  indicate  how  badly  a 
change  is  needed  (this  last  area  would  have  to  be  filtered,  or  ranked, 
later  in  view  of  all  other  needs  using  a  process  such  as  an  Analytical 
Hierarchy  Process). 

6)  15  DEC  87:  REQUIREMENTS  CAPTURE:  How  can  user  input 
concerning  needed  systems  evolution  be  obtained  with  minimum 
impact  on  the  current  thought  process  which  generated  the  desire? 
For  this  DSS  try:  (1)  When  user  hits  the  HOOK  BOOK  button,  the 
system  automatically  takes  a  snap  shot  of  the  screen  (2)  and,  in  a 
separate  storage  area,  presents  the  picture  of  the  screen  with  an 
open  text  field  and  graphic  tools  to  use  for  making  notes  and 
changing  the  presentation,  (3)  The  system  automatically  records  the 
date/time,  user,  and  other  information  required  to  reestablish  the 
context  of  the  original  comments.  (4)  A  RETURN  button  to  take  the 
user  immediately  back  to  the  point  where  he  was  when  he  left. 


7)  5  JAN  88:  STORYBOARD  DEVELOPMENT/ REQUIREMENTS 
CAPTURE:  Any  system  is  very  time  intensive  for  the  user  if 
storyboards  must  be  developed  from  SCRATCH;  BUT,  if  there  is  a 
library  of  "building  block"  parts/icons  available  to  build  new  screens 
then  the  user  can  build  a  screen  or  screens  fairly  quickly  and  show 
them  to  a  designer.  THUS,  a  ready  library  would  ease  use  of  the 
system  and  thereby  encourage  the  use  of  a  system  to  build 
storyboards  and  decrease  user  construction  time.  The  storyboards 
would  provide  a  ready  and  well-defined  basis  for  user-designer 
communications  and  thereby  hopefully  result  in  decreased 
miscommunications  between  the  builder  and  user. 

8)  23  FEB  88:  USER  STORYBOARDING:  CAN  a  user  use  the 
storyboarding  process?  Will  a  user  WANT  to  use  the  process? 

Would  a  HyperCard-like  environment  be  acceptable  to  a  user  for 
storyboarding?  A  user  can  do  storyboarding  and  will  use  the  process 
if  it  results  in  getting  better  tools  to  do  his  job.  Therefore,  a  user 
will  use  storyboarding  IF  the  storyboarding  process  is  easier  and 
quicker  than  the  process  currently  possible.  To  meet  these  goals,  a 
user  must  be  given  a  library  of  frames  and  icons  close  to  what  is 
needed  to  quickly  build  a  needed  representation  AND  an  easy,  very 
"user  friendly"  application  to  support  the  building  of  storyboards. 

This  library  might  be  developed  by  the  designer/builder  based  on 
initial  conversations  with  the  user  during  the  initial  research  of  the 
problem.  The  HyperCard  environment  is  very  easy  to  use  and  would 
supply  a  dynamic  dimension  to  a  user  developed  storyboard.  It 
might  be  used  if  the  initial  storyboard  construction  was  easier. 
Regardless  of  whether  the  storyboards  are  actually  constructed  by 
the  user  or  the  designer/builder,  the  user  should  be  intimately 
involved  with  the  construction  process.  This  is  because 
storyboarding  requires  a  thorough  analysis  of  the  process  to  be  aided 
which  in  turn  often  results  in  valuable  insights  into  the  aided 
process. 


Adaptive  DSS  Design.  The  process  of  adaptive  design  is 
encapsulate  by  the  phrase  "start  small  and  grow."  The  small  starting 
point  is  the  kernel.  One  way  to  choose  the  kernel  is  through  the  use 
of  concept  maps.  Concept  maps  will  show  the  relations  between  the 
various  ideas  and  functions  that  make  up  a  process  and  from  these 
component  parts  a  subprocess  can  be  selected  to  be  the  starting  point 
or  kernel  of  the  ultimately  complete  system.  The  designer/builder 
can  implement  this  subprocess  using  the  concept  map  as  an  initial 
cut  at  bounding  process.  Fine  definition  of  the  bounds  occurs  during 
the  storyboarding  process.  Staying  within  the  bounds  is  not  easy. 

1)  12  FEB  88;  CONCEPT  MAPS  AND  DSS  DESIGN  /  CONSTRUCTION: 

It  is  very  difficult  to  stay  within  the  confines  of  a  single  kernel  when 
trying  to  design  and/or  implement  the  first  parts  of  a  DSS.  This 
seems  to  be  due  to  the  extensive  amount  of  interrelated/overlapping 
information  that  is  shared  with  other  kernels  of  the  DSS  which 
results  in  the  designer/builder  quickly  finding  themselves  working 
in  other  than  originally  intended  areas.  This  defeats  the  purpose  of 
kernel  implementation  if  the  system  is  not  contained  within  the 
original  bounds  because  it  slows  the  system's  development/  fielding. 
Additionally,  the  designer/builder  finds  himself  quickly 
overwhelmed  by  the  size  of  the  more  complete  system.  This 
problem  might  be  avoided  by  turning  the  concept  map  of  the  kernel 
into  a  guidebook  in  the  form  of  a  checklist  (?)  and  referring  to  it 
often,  possibly  checking  off  those  areas  that  have  been  completed 
and  confirming  what  is  needed  next. 

Follow  2  on  Research:  General.  Many  of  the  comments  and 
suggestions  made  throughout  this  thesis  and  appendix  will  require 
further  study  and  research.  The  areas  commented  on  in  this  section 
are  not  easily  categorized  to  one  of  the  foregoing  sections  but  are 
very  pertinent  to  both  the  ECCO  DSS  as  well  as  to  systems  beyond  the 
ECCO  DSS. 


1)  20  AUG  87:  ALTERNATIVE  GENERATION:  The  DSS  needs  to 
incorporate  an  ACTIVE  ALTERNATIVE  suggestion  capability  initiated 
by  the  machine. 

2)  27  AUG  87:  ALTERNATIVE  GENERATION:  How  does  the  DSS  aid 
the  user  in  the  area  of  alternative  generation?  May  be  able  to  use  a 
library  of  war-game  developed  ideas/scenarios  in  a  relational  data 
base.  This  would  enable  the  filtering  of  the  many  scenarios  based  on 
the  needs  of  the  user  at  the  time. 

3)  - 88:  ALTERNATIVE  GENERATION:  Under  situations  of  high 

time  stress,  might  want  to  have  available  to  the  DSS  prestructured 
("canned")  alternative  templates  (concept  of  templates  borrowed 
from  cognitive  sciences  and  the  field  of  Artificial  Science)  (17:951). 
These  could  be  keyed  by  solution  drivers  which  would  generally 
mean  the  constraints  of  the  problem  such  as  the  number  and  mix  of 
the  EC  assets.  A  decision  tree  could  be  set  up  based  on  the  type  of 
aircraft  for  the  decision  tree  level  and  the  number  of  that  type 
aircraft  being  the  different  possible  branches.  At  the  end  of  the 
branching,  which  represents  the  current  combination  of  aircraft, 
there  could  be  a  set  of  plans  which  are  themselves  differentiated  by 
the  threat  environment  and  mission.  Therefore,  the  number  of 
mission  templates  would  equal  at  least  the  number  of  possible  threat 
environments,  n,  multiplied  by  the  number  of  missions,  m.  Beyond 
this  number,  it  would  be  best  to  have  two  or  three  plans  for  each 
threat-mission  combination,  each  addressing  other  key  mission 
aspects.  This  would  lead  to  a  total  number  of  3  *  m  *  n  *  (the 
number  of  aircraft  combinations). 

DSS  Evaluation  of  Operations.  It  is  a  matter  of  the  utmost 
faith  (and  definition)  within  the  field  of  Operations  Research  that  a 
process/problem  can  be  modeled  and  thereby  quantitatively 
measured  using  one  or  several  of  the  many  purely  quantitative  and 
pseudo-quantitative  tools  available  for  the  purpose  of  achieving 
optimal  decision  making  (16:6).  Some  processes  are  more  difficult  to 
measure  or  evaluate  than  others  due  primarily  to  a  lack  of 
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understanding  of  the  full  details  of  the  process's  interactions.  One  of 
these  processes  is  war  of  which  EC  is  a  subset. 


o\ 


1)  24  SEP  87:  ALTERNATIVE  VALUATION:  How  do  you  value  EC 
assets  and  assess  their  impact  on  the  environment  so  as  to  measure 
one  plan's  value  and  comparative  ranking  over  another  plan? 

2)  29  SEP  87:  IMPACT  MEASUREMENT:  Initial  Cut  -  Given  the 
commander's  objectives,  a  gross  idea  is  needed  of  the  combined 
worth  of  the  planned  attack  force's  capabilities,  the  worth  of 
individual  force  components,  the  value  of  its  limitations,  the  worth 
of  mission  roles  in  contributing  to  the  mission  objective, 
environment,  and  the  worth  each  subportion  to  the  overall  mission 
(i.e.,  what  is  the  worth  of  hitting  a  specific  GCl  site  in  a  highly 
redundant,  overlapping,  and  interconnected  GCI  system  to  the 
outcome  of  the  mission  as  versus  the  risk  and  impact  on  future 
missions  of  exposing  the  assets  to  the  threat  environment  in 
supporting  the  strike  against  that  GCI  site?  If  the  assets  were  to 
have  been  exposed  to  threats  in  their  original  tasking,  then  the 
subsequent  exposure  to  a  threat  environment  under  retasking  is  not 
a  change  ("sunk  cost")  and  therefore  is  not  a  valid  criteria.  The  new 
criteria  might  be  the  difference  between  the  worth  of  the  originally 
tasked  air  forces  versus  their  increased  worth  as  a  result  of  reduced 
attrition  due  to  augmentation  by  EC  forces.).  A  JMEMs  (Joint 
Munitions  Effectiveness  Manuals)  style  data  source  is  needed  which 
would  provide  EC  information  and  known  capabilities  against  various 
individual  targets  and  combinations  of  targets  (6).  This  would  be  an 
initial  step  in  developing  this  measurement  capability,  allow  for  the 
comparison  of  forces  versus  targets,  give  planners  the  ability  to  do 
measured  trade  offs,  and  help  establish  target  inherent  worth  both 
from  the  aspect  of  the  target's  system  worth  and  cost  to  friendly 
forces. 

3)  - 88:  VALUATION  CAPABILITY  (A  SURROGATE  MEASURE 

OF  A  C2  SYSTEM):  A  capability  to  evaluate  the  loss  of  friendly 
assets  versus  enemy  damage  is  needed.  This  could  be  used  as  a 
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measure  of  a  C2  system  by  measuring  the  difference  between  the  kill 
ratios  of  a  C2  system  using  a  modification  of  interest  and  a  C2  system 
not  using  the  modification. 

To  choose  between  alternatives  there  must  be  a  basis  of 
comparison.  This  is  a  field  that  has  still  to  be  satisfactorily  addressed 
within  the  area  of  warfare  and  especially  within  both  the  fields  of 
electronic  combat  and  command  and  control.  Serious  and 
concentrated  research  is  still  badly  needed  in  these  areas. 


The  ECCO  DSS  and  Its  Environment 


The  question  of  retasking  is  a  large  and  very  complex  one.  In 
working  through  the  development  of  the  ECCO  DSS  there  was  the 
constant  requirement  to  focus  on  a  tightly  defined  area  and  note 
requirements  for  work  in  other  areas.  The  following  four  parts  are 
the  result  these  observations  and  constitute  the  divisions  of  this 
section  of  the  appendix: 

1)  Degraded  Operations, 

2)  DSS  Improvements, 

3)  Adaptive  Design  of  the  ECCO  DSS;  Future  Areas  for 
Evolution, 

4)  Deconfliction. 

Degraded  Operations.  Any  system  fielded  to  operate  in  a 
warfighting  environment  must  be  able  to  operate  and  accomplish  its 
design  function  under  the  most  adverse  conditions.  This 
environment  is  unique  in  that  the  system. itself  is  being  actively 
targeted  for  destruction.  Consequently,  the  system,  whatever  type 
of  system  it  may  be,  must  be  able  to  function  even  while  damaged. 


1)  21  AUG  87:  DEGRADED  OPERATIONS:  Some  work  needs  to  be 
done  to  address  how  the  DSS  will  operate  in  a  degraded  mode  due  to 
loss  of  intelligence  inputs,  how  to  prevent  the  loss  of  these  inputs, 
the  possibility  of  minimizing  the  impact  of  losing  information  input 
by  ensuring  that  other  systems  throughout  the  C2  system  have  some 
capability  to  reproduce  various  aspects  of  the  functions  of  the  ECCO 
DSS. 

2)  22  AUG  87:  DEGRADED  OPERATIONS:  The  impact  of  degraded 
operations  can  possibly  be  somewhat  ameliorated  through  the 
continual  sharing  of  information  between  command  centers  and 
systems,  the  use  of  common,  shared  data  bases,  and  overlapping 
functionality  of  fielded  systems  to  enable  one  or  more  systems  to 
replace  tlie  loss  of  another  system. 

3)  2  FEB  88:  DEGRADED  OPERATIONS:  Throughout  the  operation  of 
the  system  snapshots  of  data  and  presentations  are  stored,  primarily 
to  allow  the  historical  representation  of  the  war  but  also  to 
accomplish  operations  if  the  input  source  goes  down.  This  stored 
information  can  be  used  to  PROJECT  enemy  movement  with  an 
ASSOCIATED  CONFIDENCE  LEVEL.  This  confidence  level  on  the 
information  being  presented  will  change  as  a  function  of  time. 

Updates  of  this  information  will  restore  the  confidence  level  but  the 
confidence  level  will  immediately  continue  to  decay  after  the  update. 

4)  13  FEB  88:  DEGRADED  OPERATIONS:  What  happens  when  the 
input  link  showing  the  current  EOB  (Electronic  Order  of  Battle)  goes 
down?  It  may  be  possible  to  use  the  last  or  best  resent  (information 
with  the  highest  available  confidence  level  within  the  last  three 
hours)  available  information  of  the  EOB  with  historically  based  state 
vectors  to  show  where  depicted  units  are  headed.  These  would  also 
have  an  associated  confidence  level  which  is  time  dependent.  After  a 
sufficient  amount  of  time  has  elapsed  so  that  the  confidence  level  is 
unacceptable  then  the  system  shifts  to  using  updates,  such  as  crew 
debriefs,  in  conjunction  with  enemy  doctrinal  template  models  to 
project  courses  of  action. 


There  are  a  myriad  of  other  aspects  to  the  problem  of  degraded 
operations  of  combat  operations  systems  that  must  be  addressed  as 
well  as  the  few  mentioned  here.  In  the  consideration  of  this  specific 
system  it  quickly  becomes  obvious  that  it  is  very  reliant  on 
intelligence  input  information.  It  is  also  obvious  that  the  cessation  of 
this  information  could  result  in  just  so  much  metal  and  so  many 
computer  chips  sitting  around  taking  up  space  and  leaving  the 
commander  worse  off  than  before  the  system  was  introduced. 
Consequently,  the  problem  of  how  to  assure  the  continued  useful 
operation  of  this  or  any  other  C2  DSS  that  relies  on  external 
information  input  is  very  important.  The  use  of  historically  based 
trends  in  enemy  actions  to  be  used  as  the  initial  input  for  models 
used  to  project  continued  enemy  actions  may  be  one  way  of 
addressing  the  problem. 

DSS  I  m prove ments.  This  section  addresses  improvements 
necessary  to  the  operation  of  the  ECCO  DSS  besides  those  obvious 
improvements  of  the  ECCO  DSS  due  to  its  expansion  to  serve  in  the 
many  other  areas  cited  in  the  concept  maps. 

1)  . :  JOINT  /  COMBINED  OPERATIONS:  Above  all  else  the 

DSS  should  be  cooperatively  expanded  to  include  the  capability  to 
handle  all  US  armed  forces  EC  assets  as  well  as  all  allied  EC  assets. 

This  should  be  done  even  before  the  completion  of  the  DSS  to  handle 
all  aspects  of  the  current  three  systems  for  at  least  two  reasons;  (1) 

A  cooperative  effort  would  represent  a  "political"  acceptance  within 
the  services  of  the  need  for  truly  integrated  operations,  and  (2)  The 
planned  integration  of  other  assets  would  insure  that  data  bases, 
models,  and  control  mechanisms  are  kept  flexible  enough  to  handle 
the  later  inclusion  of  these  systems. 

2)  -  AUG  87:  GENERAL  CHARACTERISTICS:  DSS  elements  must 
have  TRAINING/EXERCISE/DIAGNOSTIC  capabilities  embedded.  This 
overcomes  the  cost  of  constructing  additional  training  facilities  as 
well  as  the  loss  of  realism. 


3)  -  AUG  87:  DISPLAY  REQUIREMENTS:  Need  to  enhance 
presentations  by  enabling  the  display  of  range  rings,  "tiine-to-go" 
rings  for  selected  systems,  allow  the  selection  of  geographic 
orientation,  enable  the  display  of  azimuth  and  range  between 
selected  objects,  and  the  use  color  (in  a  consistent  manner). 

4)  29  SEP  87:  EC  PLANNING  MEMORY  AID:  Need  operational 
planning  aid  to  give  general  information  on  different  EC  systems  such 
as  mission  roles,  capabilities,  limitations,  notes  on  interaction  with 
other  systems,  and  other  pertinent  data.  Also,  the  system  should 
have  the  capability  to  display  similar  information  on  specific  assets 
in  the  air,  such  as  its  equipment/  ordinance  configuration,  fuel 
state,  and  other  pieces  of  information  needed  by  the  ECCO  for 
planning  alternate  missions. 

5)  24  NOV  87:  AIR  MANAGEMENT:  Enable  DSS  to  determine  if  the 
transfer  of  assets  between  two  attack  groups  is  feasible  based  on 
time  and  system  capabilities.  Give  the  operator  an  explanation  of 
why  a  transfer  is  not  feasible  and  a  checklist  as  a  memory  aid  if  the 
transfer  is  feasible. 

6)  9  DEC  87:  IADS  TRENDS:  Enable  the  time  sequence  display  of  the 
IADS  to  show  trends  in  effectiveness,  operations,  enemy  intentions, 
goals,  as  well  as  information  on  other  subjects. 

7)  12  JAN  88:  PLANNING  MEMORY  AID:  For  each  aircraft  (when 
SHOW  VECTOR  selected)  show:  (1)  Graphic  time/speed  vector  to  give 
a  feel  for  aircraft  velocity  relations  (2)  Range  ring  which  is  a 
function  of  the  aircraft's  fuel  state  and  current  speed  or  a  selected 
speed  (3)  Maximum  operational  range  ring  which  shows  how  far  an 
aircraft  can  go,  given  a  selected  mission  profile  and  whether  or  not 
combat  tactics  will  be  used,  and  still  return  to  the  planned  landing 
base. 

8)  18  JAN  88:  MODELS:  DSS  models  which  compute  jamming  effects 
must  take  into  account  types/techniques  of  the  jamming  and  the 


victim  radar,  polarization,  range  and  power  distribution,  terrain 
influence,  weather  influence,  and  other  factors  such  as  the  changing 
radar  cross  section  of  the  aircraft. 

9)  28  JAN  88;  COMMANDER'S  GUIDANCE  MEMORY  AID;  DSS  should 
have  "CC  GUIDE"  button  which  when  selected  would  show; 

(1)  A  map  overview  of  the  area  with  the  stated  geographical 
objectives  and  associated  targets, 

(2)  A  graphic  representation  of  the  allocation  and  allotment 
break  down, 

(3)  An  aggregate  depiction,  keyed  to  the  current  area  of 
coverage,  of  the  major  air  thrusts,  objectives  and  goals, 

(4)  A  listing  of  the  commander's  guidance. 

Adaptive  Design  of  Iji^  ECCQ  DSS:  Future  Areas  for 
Evolution.  The  ECCO  DSS  must  incorporate  various  capabilities 
represented  in  the  concept  maps  of  Appendix  A  but  not  yet  designed 
into  the  storyboard  strawman  which  was  shown  to  the  users  as 
represented  by  the  507  TACC.  Areas  that  will  need  to  be  included  or 
studied  further  before  inclusion  are  discussed  in  this  section.  There 
are  also  included  some  thoughts  concerning  the  impact  of  the 
adaptive  design  process  on  the  USAF. 

1)  8  AUG  87;  COORDINATED  ASSESSMENT;  A  DSS  that  uses  multiple 
cooperative  models  which  provide  information  to  each  other  to  come 
up  with  an  evaluation  must  all  be  based  on  the  same  assumptions, 
constraints,  logic,  resolution,  tactics,  assessment  of  the  threat 
systems,  the  threats'  C2  system,  the  effects  of  friendly 
countermeasures  on  the  threat,  as  well  as  use  the  same  algorithms. 
This  coorditiation  of  the  models  will  help  lead  to  results  that  are  at 
least  consistent  (these  problems  should  be  addressed  in  the 
establishment  of  a  service-wide  management  system  to  implement 


and  maintain  a  hierarchy  of  models).  Otherwise,  the  same  questions 
and  input  will  yield  different  output. 

2)  23  SEP  87:  IADS:  The  DSS  needs  to  be  able  to  assist  in  answering 
the  question  of  what  level  to  knock  the  IADS  down  to  so  as  to  realize 
minimum  attrition  for  a  given  mission.  To  do  this,  the  DSS  needs  to 
be  able  to  display  the  IADS  C2  interconnectivity,  indicate  the  type  of 
interconnectivity  (data  link,  hard  wire,  HF/VHF  radio,  etc.),  display 
the  critical  nodes,  indicate  the  current  operational  level  of  a  unit 
(such  as  Independent,  Semi-Autonomous,  etc.),  and  be  able  to 
account  for  the  change  in  friendly  attrition  due  to  these  effects  and 
operational  levels.  ADDITIONALLY,  the  DSS  must  also  address  the 
SILENT  THREAT  (31).  Is  a  threat  system  silent  because  it  has  been 
killed?  Then  actively  targeting  it  is  a  waste  of  resources.  Or  is  a 
threat  system  silent  because  it  is  waiting  in  ambush?  How  can  this 
be  determined  and  indicated? 

3)  23  SEP  87:  EXPENDABLE  EC  ASSETS:  The  use  of  EC  assets,  such 
as  TACIT  RAINBOW,  must  be  considered  in  a  C2  problem.  QUESTION: 
Has  the  C2  and  employment  doctrine  for  these  systems  been 
developed?  Has  the  impact  on  current  doctrine  been  considered? 
These  questions  are  critical  because  they  will  dictate  how  the  ECCO 
advises  the  commander  on  the  use  of  these  and  other  EC  assets. 

4)  23  SEP  87:  MODELLING  AN  EC  ENGAGEMENT:  How  is  it  known 
when  to  initiate  jamming  of  the  model  aircraft  against  any  given 
threat?  This  will  impact  the  outcome  of  the  modelled  engagement 
and  eventually  the  analysis  of  the  alternative  plans. 

5)  29  SEP  87:  SYNERGISTIC  EFFECTS:  How  can  the 
interactive/synergistic  effects  of  electronic  combat  be  predicted 
and/or  planned  for  (6)?  Do  you  want  to  plan  for  these  effects? 
Planning  for  positive  benefits  from  these  effects  would  lead  to 
planning  a  best  case  scenario.  Planning  on  negative  benefits  from 
these  effects  would  lead  to  planning  a  worst  case  scenario.  Each  type 
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of  benefit  could  cause  a  significant  variation  in  the  support 
configuration. 

6)  29  SEP  87:  PLANNING  MEMORY  AID:  A  DSS  should  have  a 
JMEMs  type  capability  for  EC  planning.  There  needs  to  be  the 
capability  to  compare  friendly  EC  capabilities  against  adversary 
systems,  friendly  vulnerabilities  against  adversary  systems,  remind 
the  ECCO  as  to  the  appropriate  mission  role  of  assets,  and  determine 
friendly  EC  optimal  support  configurations  to  support  the  attack 
force. 

7)  29  SEP  87:  ENEMY  REACTION:  It  is  important  to  future  planning 
to  be  able  to  determine  changes  in  enemy  capabilities  due  to  EC 
actions  as  well  as  enemy  reactions  and  how  those  reactions  change 
over  time  (6).  This  knowledge  would  point  up  enemy  vulnerabilities 
and  give  indications  as  to  how  long  the  enemy  systems  might  remain 
vulnerable  before  corrective  action  closed  that  option  to  friendly 
planners. 

8)  8  NOV  87:  WARNING  OF  UNACCEPTABLE  PLAN  CHANGES:  How 
does  a  DSS  warn  the  user  that  a  change  has  occurred  in  the  plan  that 
requires  either  initiating  an  alternate  plan  or  starting  the  retasking 
process?  The  DSS  can  be  loaded  with  a  copy  of  the  mission  plans 
which  can  be  used  to  compare  with  real-time  information  of  the 
actual  missions.  Threshold  differences  can  be  set  for  various  aspects 
of  a  mission  and  when  the  difference  between  the  planned  and 
actual  mission  becomes  greater  than  one  of  these  thresholds  then  the 
system  automatically  triggers  an  alarm  for  the  operator.  These 
threshold  should  be  set  for  areas  such  as  course  deviation,  timing, 
force  composition,  attrition  levels,  and  other  items.  Additionally, 
these  thresholds  should  be  area  selectable  and  user  defined. 

9)  8  JAN  88:  UNCERTAINTY:  How  can/should  uncertainty/variance/ 
confidence  be  indicated  for  both  the  input  information  (intelligence) 
and  the  analysis  results?  Does  a  planner  need  to  know  this 


information?  Will  this  type  of  information  have  an  impact  on 
retasking? 

10^  20  JAN  88;  CURRENT  POTENTIAL:  Due  to  the  complexity  of  the 
ECCO  DSS,  it  may  not  be  possible  to  field  a  system  that  is  able  to 
accomplish  both  the  capability  requirements  and  the  speed/time 
requirements.  If  not,  it  might  be  necessary  to  first  field  a  system 
that  uses  a  'Rule-of-Thumb"  approach. 

Deconfliction.  The  requirement  to  deconflict  both 
physical  and  electromagnetic  space  is  just  the  logical  extension  of  a 
commander's  need  to  conserve  his  forces.  The  extreme  complexity  of 
a  large  military  operation  may  render  current  attempts  at  perfect 
deconfliction  completely  ineffective  and  laughable.  Deconfliction  is 
probably  a  misnomer  more  properly  termed  Conflict  Management. 

1)  29  SEP  87;  DECONFLICTION:  For  the  purposes  of  conserving 
forces,  gathering  the  best  possible  intelligence,  and  assuring  the 
best  possible  coordination  of  force  effects,  the  DSS  should  be  enable 
the  management  of  (1)  the  coordination  between  combat  EC 
requirements  and  intelligence  ELINT  taskings,  (2)  the  EC  efforts  on 
the  ground  as  well  as  in  the  air,  (3)  the  coordination  of  EC  timing, 
and  (4)  ingress/egress  air  space. 

2)  9  DEC  87:  AIR  SPACE  DECONFLICTION:  How  should  airspace 
management/deconfliction  be  depicted  for  the  purpose  of 
transferring  retasked  forces?  Should  it  be  completely  a  computer 
check  of  possible  conflicts  with  other  current  or  planned  operations 
or  a  combined  computer  and  visual  depiction  check?  The  process 
could  be  as  follows; 

(1)  Currently  active  routes  and  those  ATO  planned  routes  that 
will  be  active  during  the  projected  retasking  would  be  overlaid  on 
the  overview  display, 

(2)  The  proposed  route(s)  would  then  be  overlaid  on  the 
overview  display. 


(3)  The  system  would  simulate  the  plan  and  do  a  point  by 
point  evaluation  of  the  proposed  routes  to  check  for  conflicts  in  both 
time  and  altitude, 

(4)  Real  world  flight  activities  do  not  arrive  at  points  exactly 
as  planned  but  instead  arrive  with  some  amount  of  error  in  their 
arrival  times  as  compared  to  their  planned  arrival  time.  The  same  is 
true  with  respect  to  altitude.  Consequently,  "conflict"  in  planning 
could  be  defined  as  whenever  two  aircraft/forces  come  within  two 
sigma,  or  two  times  the. standard  deviation  from  their  mean  arrival 
time/altitude,  of  each  other  in  terms  of  either  altitude  or  time. 

These  could  be  differentiated  by  color.  The  conflict  could  be  coded 
red  if  the  conflict  was  within  one  sigma  for  both  forces.  It  could  be 
coded  orange  if  the  interaction  was  within  one  sigma  for  only  one 
force  and  between  one  and  two  sigma  for  the  other  force.  The 
conflict  could  be  coded  yellow  of  the  conflict  was  between  one  and 
two  sigma  for  both  forces. 
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The  air  commander's  ability  to  shape  and  control  the  battle  is 
just  as  critical  for  victory  in  the  air  as  it  is  on  the  ground.  The 
inability  of  the  commander  to  control  his  forces  in  a  timely  manner 
will  see  them  defeated  by  a  more  flexible  opponent.  Decision 
support  systems  (DSS)  are  a  tool  which  can  aid  the  commander  by 
giving  the  overwhelming  masses  of  information  a  structure  for  the 
decision  process  at  hand  and  by  aiding  the  evaluation  of  this 
information. 

The  problem  of  being  inundated  by  data  also  applies  to 
electronic  combat  (EC)  assets.  The  commander's  control  of  a  these 
scarce  resources  requires  a  complex  assessment  of  an  enemy's  air 
defense  system  and  the  determination  of  how  to  employ  EC  assets  to 
gain  the  best  degradation/destruction  of  those  defenses. 

To  develope  a  DSS  to  aid  the  commander,  the  functions  and 
requirements  of  the  system  must  be  established.  The  purpose  of  this 
thesis  was  to  investigate  the  use  of  the  storyboarding  process  as  a 
vehicle  for  the  establishment  of  systems  requirements.  The  DSS 
focused  on  for  this  study  was  an  aid  to  the  Electronic  Combat 
Coordination  Officer  (ECCO)  for  the  dynamic  retasking  of  airborne  EC 
assets.  The  adaptive  design  process  was  used,  therefore  only  a  small 
core  was  initially  proposed.  The  remainder  of  the  system  would 
follow  as  further  requirements  were  generated. 

The  main  objectives  of  this  research  were:  (1)  Model,  through 
concept  mapping,  the  probable  decision  process  of  the  ECCO  for  the 
retasking  of  EC  assets.  (2)  Continue  the  investigation  into  the 
effectiveness  of  paper-based  storyboarding  in  determining  system 
requirements.  (3)  Investigate  the  possibility  of  using  a  computer- 
based  storyboarding  process  with  the  aim  of  determining  the 
feasibility  of  user  generation  of  system  requirements. 

The  results  indicate  that  the  storyboarding  process  is  excellent 
for  the  unambiguous  communication  of  requirements.  There  is  every 
indication  that  computer-based  storyboarding  can  prove  to  be  even 
more  effective  by  taking  the  user  one  step  closer  to  the  actual 
system  and  may  thereby  enable  the  generation  of  system 
requirement  by  users  in  the  field. 


mCU! 


